[FFmpeg-trac] #8066(avcodec:open): Bad quality encoding of high compressed audio by AAC encoder

[FFmpeg]

#8066: Bad quality encoding of high compressed audio by AAC encoder
------------------------------------+-----------------------------------
             Reporter:  Lirk        |                    Owner:  Lynne
                 Type:  defect      |                   Status:  open
             Priority:  normal      |                Component:  avcodec
              Version:  git-master  |               Resolution:
             Keywords:  aac         |               Blocked By:
             Blocking:              |  Reproduced by developer:  1
Analyzed by developer:  1           |
------------------------------------+-----------------------------------

Comment (by marcan):

 While cascading is certainly not the ultimate encoder test, I disagree
 with the premise that it isn't a good idea because you can "cheat".
 Allowing sideband data is a silly idea for this test; you'd do it by going
 through a pipeline where the only thing between repeated encodings is
 plain PCM.

 Repeated encodes can bring out artifacts and problems which are harder to
 discern in a single encode. Additionally, single-digit number of
 transcodes are a thing in valid use cases, and something worth optimizing
 for. An encoder that produces 10% better quality than another encoder at a
 single encode, but 40% worse quality after 2 encodes, is an inferior
 encoder for a lot of practical use cases (and if that tradeoff really must
 be made, that should be a configurable option so both use cases are
 covered).

 For what it's worth, libfdk_aac seems to be exceptionally stable. At 100
 repeat encodes at 128kbps, it still produces listenable output, with
 somewhat patchy high frequency bands but otherwise no added distortion nor
 level changes. I would subjectively rate it on par with ffmpeg-aac after
 just 6 transcodes. At that point ffmpeg-aac has more high frequency
 content, but also has more audible *added* noise/artifacts. Those add up
 to complete destruction by the time you get to 100 transcodes. Sure, 100
 transcodes is a silly use case, but the results still sound like they
 should lead to some insight as to how to improve the encoder.

 Also, consider that already encoded audio is perfectly valid PCM after
 decoding, and a useful sample to test encoding on. While there are
 subtleties regarding whether an encoder encoding its own output would have
 an advantage vs encoding another encoder's output (or another dodec's
 entirely), this is still not a test to be dismissed on the face of it.
 This whole thing started for me because a practical MP3 (256k) -> ffmpeg-
 aac (320kbps) -> ffmpeg-aac (320kbps) pipeline had noticeably worse
 artifacts than replacing just the last step with libfdk_aac at the same
 bitrate, or even at 128kbps. I posit that 320kbps should be effectively
 transparent for essentially all samples, and should remain so even after a
 few transcodes. The sample that started this all is not transparent for me
 after just 2 rounds of ffmpeg-aac at 320kbps (>99% confidence), but is
 after 100 rounds of libfdk_aac at the same bitrate.

 Just to add some relevant references:
 - ffmpeg-aac vs libfdk_aac listening tests:
 https://hydrogenaud.io/index.php?topic=111085.0
 - A few user reactions to quality improvements after switching from ffmpeg
 to CoreAudio in the comments: https://obsproject.com/forum/resources/obs-
 studio-enable-coreaudio-aac-encoder-windows.220/

 (meta: I "recruited an army on twitter" because last time I raised an
 issue about this I was effectively ignored/dismissed as crazy and
 imagining artifacts, and this time, before making the twitter thread, I
 was linked to this ticket by another user, where I saw that the immediate
 response from a developer in comments 1 and 3 was dismissive, rude, and
 outright had not paid attention to what the user who opened the ticket had
 actually said; this was followed by the ticket being closed NEEDINFO by
 another person with no further explanation or request for info, even
 though the original user who opened it attempted to calmly clarify what
 the problem was. I started the Twitter thread after seeing this; then I
 had a request for info from @ffmpeg, which I did provide (after
 considering for a while whether I really should be spending more of my
 time on this), and this was followed by more rude responses aimed at me
 from yet another ffmpeg developer. If ffmpeg developers expect users to
 "file a bug or ping a developer", I would recommend reacting politely and
 listening when users do exactly that, and perhaps consider whether keeping
 certain developers around who alienate users is a net benefit for the
 project. I am happy to provide samples and perform listening tests if they
 are going to be taken seriously, but so far that hasn't happened and I'd
 like some reassurance that they will before I waste more of my time on
 this.)

--
Ticket URL: <https://trac.ffmpeg.org/ticket/8066#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker