#11578(ffmpeg:new): Waveform discontinuity in decoded E-AC-3
#11578: Waveform discontinuity in decoded E-AC-3 --------------------------------+--------------------------------------- Reporter: j7n | Type: defect Status: new | Priority: normal Component: ffmpeg | Version: unspecified Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | --------------------------------+--------------------------------------- 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 }}} -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: (none) Type: defect | Status: new Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Changes (by j7n): * Attachment "whatifwe.ec3" added. glitch at sample 187136 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: (none) Type: defect | Status: new Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Changes (by j7n): * Attachment "pourque.ec3" added. glitch at sample 41728 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: (none) Type: defect | Status: new Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling): Does the same happen with mp4? As in the same eac3 stream in mp4 reference container. Also does it sill happen if you decode to 24 bits, as you are supposed to? ffmpeg -i file.ec3 -c:a pcm_s24le fike.wav -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:1> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: (none) Type: defect | Status: new Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by j7n): Yes and yes. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:2> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Changes (by Balling): * owner: (none) => mkver * status: new => open Comment: 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 usinf non-ffmpeg code. Great. I thought Android uses dolby binaries. Will also check LG C9 hw decoder. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:3> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling): I found this album on the torrents, so indeed, the correctly mp4 file does not cause this artefact on Adnroid because the nice Dolby decoder is used to decode it. (Mx player and Samsung player support this, VLC does not.) Artefacts are bug in ffmpeg. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:4> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by j7n): The bug also doesn't occur in Adobe Audition CC 2017, which, surprisingly, can decode dolby digital. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:5> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling): Replying to [comment:5 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 2015, it is much better. Also, it cannot decode Atmos part, obviously. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:6> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:7> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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 -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:8> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling):
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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:9> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:10> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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.
It certainly is, -c copy should fix it. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:11> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:12> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling): Well, last part does not matter since in the browser ffmpeg was modified to decode gaplessly. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:13> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by Balling): So if you seek the decoded audio is different from if you seek normally This appears to be a duplicate of bug #10732, but I hoped it got fixed. Sigh. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:14> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
#11578: Waveform discontinuity in decoded E-AC-3 -------------------------------------+---------------------------------- Reporter: j7n | Owner: mkver Type: defect | Status: open Priority: normal | Component: ffmpeg Version: unspecified | Resolution: Keywords: eac3 | Blocked By: Blocking: | Reproduced by developer: 0 Analyzed by developer: 0 | -------------------------------------+---------------------------------- Comment (by 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. -- Ticket URL: <https://trac.ffmpeg.org/ticket/11578#comment:15> FFmpeg <https://ffmpeg.org> FFmpeg issue tracker
participants (1)
-
FFmpeg