[FFmpeg-trac] #2686(avcodec:open): Native AAC encoder collapses at high bitrates on some samples

[FFmpeg]

#2686: Native AAC encoder collapses at high bitrates on some samples
-------------------------------------+-------------------------------------
             Reporter:  Kamedo2      |                    Owner:
                 Type:  defect       |                   Status:  open
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  aac          |               Blocked By:
  regression                         |  Reproduced by developer:  1
             Blocking:               |
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by Kamedo2):

 Replying to [comment:167 klaussfreire]:
 > Not sure how you compare abr vs vbr, what I do is pick a file or set of
 files, do a binary search of the quality level that results in the same
 overall file size, and then compare. In that kind of test, v6 vbr
 sometimes requires '''lots''' more bits for some pathological files
 (techno seems to drive it crazy, can't blame it). I exclude those, since
 they're pathological.

 I compare abr vs vbr by a graph. I plot a "q vs bitrate" graph over a
 "standard" set of large set of sounds I extracted from diverse CDs. Then,
 search a number of q that have the desired bitrate. Then, make sure that
 average tested sample bitrate isn't very far from the "standard" bitrate.
 This method is common in the hydrogenaudio.
 http://listening-tests.hydrogenaudio.org/sebastian/mp3-128-1/index.htm


 > When I push the patches to the ML, I'll make most of what makes v6 vbr
 go crazy on techno (the relatively high peak bit rate allowance)
 configurable anyway.
 I think it's a good idea to automatically "cap" the bitrate based on the q
 number. 3x of the "standard" bitrate of the q or something.

 Also, I think it's beneficial for the end users to set the -q:a value and
 typically gets a file with the bitrate around the set value. If one sets
 -q:a 256k, one gets a file of roughly 256kbps. (Or 210kbps, 289kbps, etc
 based on the sound content, but that's fine.) iTunes have that interface,
 and it's easier to use. This can be controversial as people may refer to
 some old documents of -q:a option and try to do the same, but the problem
 can be avoided by moving to a "classic mode" when the value is very small,
 like -q:a 0.3.

-- 
Ticket URL: <https://ffmpeg.org/trac/ffmpeg/ticket/2686#comment:168>
FFmpeg <http://ffmpeg.org>
FFmpeg issue tracker