[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):

 You're right that cascading with frame alignment is a best case scenario
 and not representative of typical streaming/etc use cases. Anecdotally,
 this also aligns with how when I noticed the artifacts from 2x 320k
 ffmpeg-aac done through two instances of OBS, they seemed fairly evident
 (presumably not frame aligned), while when I did an ABX test later (with
 the cascading aligned), I still was able to tell but it took more careful
 listening. (Unfortunately the 2xOBS test was literally with two people on
 the other side of the planet both running OBS and a DJ setup as the input,
 so I can't literally reproduce it as is, though I can try to approximate
 it).

 But either way, having aligned inputs is a best case scenario, so it makes
 sense that the encoder ought to do a good job then at least.

 I'm attaching the sample I used for the 2x 320kbps ABX test, which was the
 song that was playing via the DJ/OBS pipeline when I first noticed the
 artifacts. I need to try it at a single encode and see if I can still tell
 it apart. It is sourced from a 44.1 256kbps MP3 (no better source is
 available), but that should be mostly irrelevant, just treat it as a blob
 of PCM data that AAC encoders may do a better or worse job on.

 Meta:
 ffmpeg may not be a very organized project, but the actions of its
 developers and other members reflect on the project as a whole, and
 tolerance of misbehavior by other developers indirectly reflects on them.
 The reason why some projects are adopting codes of conduct and such is to
 have a more unified view of what kind of community the project is
 attempting to foster. While deciding whether to actually do that and what
 the contents should be is a massive debate and can of worms I'm not going
 to open here, the underlying fact here is that projects aren't just loose
 collections of independent developers; they have a shared image and the
 project as a whole, and other members, are not insulated from the actions
 of others. Having things literally implemented as a free-for-all with no
 consequences for those who act poorly towards users does not excuse other
 developers who may not be directly the problem, but enable those who are
 by doing nothing about it. Whether it be via codified rules like a CoC, or
 via informal discussion and consensus among members, projects need to
 manage their image just like any other organization.

 I'm sorry that you got personally attacked in private. For what it's
 worth, I've been a notable public face of a certain project/community in
 the past, so I know what getting that stuff is like, and it's a big reason
 why I burned out of ever taking that kind of role again in that field. My
 issues with the AAC encoder are not intended as demands for improvement,
 nor to mock the project, but rather my frustration stems from the claim of
 superiority over FDK (which seemed patently absurd to me, I've yet to see
 a sample where FDK was clearly worse), which seems misleading towards
 users; and at the animosity towards me for trying to bring the issue up. I
 have no problem with an encoder that isn't ideal as long as it is
 documented as such, and of course I would support any improvements to it,
 so long as honest feedback/test results from me are taken seriously.
 Unfortunately, last time I brought this up (again with samples) nothing
 changed in the docs; it seems this time around a patch was posted to
 remove the claim, so perhaps that will be fixed soon. And I do hope the
 encoder does improve to the point where it surpasses FDK some day.

 The line about h.264 vs aac encoders was not intended to put them on equal
 footing. It was merely a comment on the paradoxical status quo where, of
 two proprietary and patented codecs which are most often used together,
 the open source world has probably the best encoder for one, and only
 fairly mediocre support for the other. I understand *how* that happened,
 it's just a comment on the weird state of things.

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