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 reminds me I should submit a patch

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

[Balling]

I found out how to manage to decode this file "correctly", the same bug exists in the open source decoder of Atmos Cavern.

So, create file mylist.txt in user directory with contents

file 'right.m4a'
file 'right.m4a'

then ffmpeg -f concat -i mylist.txt -c copy output121.mp4

then the mp4 file will be decoded:

ffmpeg.exe -drc_scale 0 -i output121.mp4 -c:a pcm_s24le fafafaws1.wav

So now after first 4 minutes song begins again. BOOM, no artefact.

I will cut the first 11990016 samples and last 11990016 samples and convert to flac. But bad news is that the files are very different but sample synchronized... Another fun fact is that even if you convert this 24 bit flac to -c:a pcm_u8 the bug is still clearly there.

If you sum the track with the inverse of the other the artefacts are all over the audio, but only one place has this clear artefact. I don't even understand what kinda issue is that though.

​https://drive.google.com/file/d/19ou0lr-IsqhyDJIGvEgKyliEWMdehmKh/view?usp=drivesdk

[j7n]

Glitch at sample 358 656

[j7n]

I have since encountered this bug with more streams, always near the start of playback, but at slightly different times. Prepending silence doesn't fix the problem. But prepending another clip with the glitch fixes it. For example, whatifwe.ec3+pourque.ec3 will not have a glitch during pourque.

Difference between decoding from different points is expected because of dithering in bands that don't have bits in the mantissa. Most of the difference is found in the highest frequencies.

[Balling]

Difference between decoding from different points is expected because of dithering in bands that don't have bits in the mantissa

Erm, okay maybe you will have to detect such abrupt amplitude change and verify that decoding from a different position does not cause it? Any idea??

silence doesn't create decoder-side spectral history...

The issue is probably somehow in here ​https://github.com/FFmpeg/FFmpeg/blob/415b466d41ac81856abc76d7a9341132b0f668b0/libavcodec/ac3dec.c#L1065

[Balling]

BTW, it does not reproduce when you directly ffplay the audio for whatever reason. Only when you do

ffmpeg -drc_scale 0 -i whatifwe.ec3 -c:a pcm_s32le fcdawsf.wav

So I guess something initialises wrong??

So how does one dump ffplay audio directly? Same about mpv btw... Hmmmm... mpv supports dump and you can SEEEEEKKKKKK right when it is dumping: boom!!!

mpv.com --target-colorspace-hint=yes --target-colorspace-hint-mode=source-dynamic -vo=gpu-next -gpu-api=d3d11 -hwdec=auto -dither=no "M:\Celine Dion - [2007] Taking Chances {surround}\13 - Right Next to the Right One.m4a" --ao=pcm --ao-pcm-file=out2121put.wav

Now, since it seeked the audio is valid and starts from first frame of eac3 and yet the dither is different again, so I guess the bug is in the dither. 32 bit flac here...

"glitch at sample 187136" that is wrong, btw. the glitch is earlier at 171842 and ends at 172162.

If you invert the track and mix them together in Audacity the artefact looks like this:

[j7n]

A fade-in at 187136 across 3 chnls

[Balling]

Oh, audition moves the samples vs Audacity. I had to change audacity project sample rate to 48000. Fixed now, you are correct.

[Balling]

It appears in ffplay bug only happens with ffplay -downmix 2 file.eac3

and does not happen with ffplay -downmix stereo file.eac3 (apparently because downmix option does not respect the downmix to 2.0 metadata unlike -ac 2 option)

which is the default.

Oh, wait, downmix 2 actually produces all base layer channels. Whatever.

[Balling]

Found where this was originally reported with waveform picture issue
​https://forum.doom9.org/showthread.php?p=2018346#post2018346

[Balling]

This says FFmpeg uses a lagged Fibonacci generator (av_lfg_get) and may be problematic. Also says that Dolby decoder has less noise. ​https://rationalqm.us/board/viewtopic.php?p=23569#p23569

See also ​https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/fbdb0313f53f84f5a8a5a23ad1880bf7ef4dcc5f

I was wrong and dither amplitude is actually okay-ish what is not okay is that it dithers the coupling channel instead of resultant channels.

[Balling]

And what are we gonna do about this? This change is far from perfect ​https://github.com/librempeg/librempeg/commit/595b76c23b232414039b48ae0a18f1d716d65a9c

​https://hydrogenaudio.org/index.php/topic,129241.msg1078674.html#msg1078674

[Balling]

Re: doom9.

Well, the click does not happen on Paul B's work. I checked it does not happen anywhere and dither makes the new audio cleaner too. And now we have a PROBLEM. ​https://github.com/rorgoroth/mingw-cmake-env/releases/tag/latest

The problem is whether we can upstream the fix.

[Balling]

Yea, I compiled ffmpeg and it is not that patch with dither that fixed it. I will find it in Paul's patch with bisecting. Sigh.

[Balling]

This is the patch that fixes this issue ​https://github.com/librempeg/librempeg/commit/049ca1424412fb50f598b869580f4124870d0c59

Submitted it ​https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23512

[Balling]

This is caused by block switching when one 512 IMDCT switches to 2 x 256 IMDCTs. In FFmpeg code downmix and IMDCT different_transforms order can change depending on downmix flag, yet that flag was incorrectly set and Paul patch above sets it correctly. ​https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ac3dec.c#L1305

This happens on any AC3 file where the block switching happens which itself happens when encoder thought that sound changed significantly, so often on music with encoded objects, but one should note that for it to be audible a lot of things have to coincide where the 2 x 256 will cause such an artefact, but it makes the sound more lossy in all cases.

But this is a regression before acbb2777e28c462d38f774d317e6cd3ad2a0b215.

This code is what added this optimisation to switch depending on downmixing

​https://github.com/FFmpeg/FFmpeg/commit/38dae9c3a63c0c5a189d0a8e2739c1635b09b547

And this is not just another regression from #11321 as even before it was an issue.

[Balling]

After further debug it turns out that only the very first time 2x256 was used in the bitstream it is not being applied in our code, which leads to the artefact, in all times after 2x256 is used (add the logging after this line ​https://github.com/FFmpeg/FFmpeg/blob/a2856b3c3084ea45ca5b94a5daded25f85c41dac/libavcodec/ac3dec.c#L576 e.g.:

av_log(s->avctx, AV_LOG_WARNING, "entered256 path\n"); )

[Balling]

Okay I did the debug finally.

The issue is that since s->downmix is always set (even when we are not requesting it) the code here

​https://github.com/FFmpeg/FFmpeg/blob/9420146e6dfb6b1ece476086f526050348897a0d/libavcodec/ac3dec.c#L1316 executes you can see it with

av_log(s->avctx, AV_LOG_ERROR, "you did not set downmix did you? "

"yea\n");

It will set s->downmix to zero but it is too late and ac3_upmix_delay(s); is executed, since s->downmix is now zero all further blocks where obly some of the channels have 256 transforms are done without ac3_upmix_delay.

You can verify that on a original file that if you change 0 to 1, now all 2x256 short blocks are corrupted and many of them cause cracks.

if (s->downmixed) {

s->downmixed = 1;
ac3_upmix_delay(s);

Removing ac3_upmix_delay(s) line from there also leads to the same effect and no 256 transforms are corrupted.

BTW, funny but ac3enc does not support short transforms.