Waveform discontinuity in decoded E-AC-3

[j7n]

Summary of the bug: Specific E-AC-3 streams with Atmos occasionally fade in from zero amplitude at a block boundary, producing a click. It only happens on the first playthrough. Rewinding to before the defect in the same player session makes the fault disappear. Channels higher than 0 in a 5.1 layout are affected. The official Dolby decoder works fine. The streams were acquired from Apple Music.

whatifwe.ec3 : glitch at 187136
pourque.ec3 : glitch at 41728
How to reproduce:

% ffmpeg -i pourque.ec3 pourque.wav
ffmpeg version n7.1.1-10-gc6c20e04cc-20250507

[j7n]

glitch at sample 187136

[j7n]

glitch at sample 41728

[Balling]

Does the same happen with mp4? As in the same eac3 stream in mp4 reference container.

Also does it still happen if you decode to 24 bits, as you are supposed to? ffmpeg -i file.ec3 -c:a pcm_s24le fike.wav

[j7n]

Yes and yes.

[Balling]

Yes, I can reproduce that. First sample is very clear. And yes, after seeking again it does fix itself.

Damn, on android no decoder is using non-ffmpeg code. Great. I thought Android uses dolby binaries, but that is only if mp4 file is tagged correctly. #9996

Will also check LG C9 hw decoder.

[Balling]

I found this album on the torrents (Celine Dion Taking chances), so indeed, the correctly tagged #9996 mp4 file does not cause this artefact in the very start on Android because the nice Dolby decoder is used to decode it. (Mx player and Samsung player support this hand over to Samsung eac3 decoder, VLC does not.) Artefacts are bug in ffmpeg.

[j7n]

The bug also doesn't occur in Adobe Audition CC 2017, which, surprisingly, can decode dolby digital.

[Balling]

Replying to j7n:

The bug also doesn't occur in Adobe Audition CC 2017, which, surprisingly, can decode dolby digital.

Adobe Audition 2017 also can encode EAC3, which was removed in 2018.

Anyway, Adobe Audition 2017 decoder was broken use Adobe Audition 2025, it is much better.

Also, it cannot decode Atmos part, obviously.

[j7n]

What is wrong in CC 2017? I notice that the top bands are sightly lower level, and the dithering doesn't have a spike on every block of 256 samples.

Where is the fault with these two tracks not being gapless in MP4? They have an overlap of 2 frames (3072 samples). In "edts"/"elst" track 05 has a recorded delay of 2688 samples, which are discarded by ffmpeg from the start. To achieve gaplessness, 384 more samples should be deleted, which doesn't happen. Track 04 has a duration of 0x38FE80 - delay of 0x0800 = 0x38F680. The actual decoded duration is decimal 3733504 (384 longer). I can open another issue if it is warranted.

​https://pixeldrain.com/u/RnRtVeKg

[Balling]

What is wrong in CC 2017?

It decodes the start incorrectly.

They have an overlap of 2 frames (3072 samples).

2 frames in EAC3 is 256*2 =512 samples. You mean 12 frames.

In "edts"/"elst" track 05 has a recorded delay of 2688 samples, which are discarded by ffmpeg from the start.

To achieve gaplessness, 384 more samples should be deleted, which doesn't happen.

It does happen: #9471

[Balling]

​​https://pixeldrain.com/u/RnRtVeKg

I do not get it. The first track has Media time: 2048 that means 2048 audio samples from the start need to be removed and they are, verify:

ffmpeg.exe -drc_scale 0 -i "04 - Allison.mp4" -c:a pcm_s24le -f md5 -

ffmpeg.exe -ignore_editlist 1 -drc_scale 0 -i "04 - Allison.mp4" -c:a pcm_s24le -f md5 -

md5 is different and you can see in audacity that 2048 samples were removed.

The other thing Track duration: 3735168 is not applied, yes, this is a known bug.

In "edts"/"elst" track 05 has a recorded delay of 2688 samples

Yes, it does: Media time: 2688 (0x00000A80)

To achieve gaplessness, 384 more samples should be deleted, which doesn't happen.

No, it should not happen, that is not what the standard says.

Track 04 has a duration of 0x38FE80 - delay of 0x0800 = 0x38F680

What? No, the standard says that mvhd (Duration: 0x0038FE80) and tkhd present the post-editlist duration, while mdhd (also 0x0038FE80 for some reason) should have the pre-editlist duration

So this is probably just broken file.

[j7n]

The linked unfixed bug #9471 explains it. The extra 384 samples are after Track Duration of track 04. If they are removed, this track splices perfectly with 05. All lossy formats have a bit of padding. Maybe the mvhd duration is set incorrectly. That's how atmos music is encoded now. This is not a unique sample, except that it contains clear sound at the cue mark.

[Balling]

The linked unfixed bug #9471 explains it

Yes, I opened that bug, I know what it says.

Maybe the mvhd duration is set incorrectly.

mdhd, not mvhd, and it certainly is, -c copy should fix it.

[Balling]

Maybe the mvhd duration is set incorrectly

Yes, it is just a bug, if you c copy the file to a new mp4 with ffmpeg, it now has:

Duration: 3735552 (0x00390000) in mdhd.

[Balling]

Well, last part does not matter since in the browser ffmpeg was modified to decode gaplessly.

[Balling]

So if you seek the decoded audio is different from if you decode normally from the start

This appears to be a duplicate of bug #10732, but I hoped it got fixed. Sigh.

[j7n]

If I seek to near the beginning when the click has already played: good audio. If I seek to a position later and back to 2 seconds: still a click.

I have three other examples all from music, but I have to listen again to find them. The click is always within a few seconds from the start. Maybe it's a peculiarity of the encoder that Apple Music uses.

An unwanted reset seems to happen between audio blocks, always in the same spot.

[Balling]

The artefacts happen in R and Rs channel.

[Balling]

Kinda the same happened with Dolby E. That remind me I should submit a patch

​https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240311140128.1730332-2-nicolas.gaullier@cji.paris/