The codec cannot do VBR, but that is not to say if you encode at around 205kbps CBR that the results would be worse than the nero codec, as far as I know this FDK codec beats the nero codec hands down.
Hi Spoon.
Sorry for bumping an old reply.
I've spent considerable time with the libfdk-aac and fdkaac source code and I can't find any evidence that "The codec cannot do VBR". Having experimented with the fdkaac command by itself, I can assure you that VBR works great in LC mode and files produced with "-m5" are high quality and smaller in size than their equivalent CBR files.
I've spent considerable time with the libfdk-aac and fdkaac source code and I can't find any evidence that "The codec cannot do VBR". Having experimented with the fdkaac command by itself, I can assure you that VBR works great in LC mode and files produced with "-m5" are high quality and smaller in size than their equivalent CBR files.
Please enable VBR in the UI.
Thanks
True that! FDK has supported both CBR and VBR since day one.
BTW, I had been doing some VBR encodes using the command-line fdkaac tool directly, and I've stumbled on a weird quirk: using fdkaac version 0.6.1 (tested with VBR, LC profile, default settings) results in m4a files whose bitrate isn't handled correctly by dBpoweramp's property handler. All such encodes show "0 kbps". MediaInfo seems to handle them correctly.
Now going back to fdkaac 0.2.0 (the version included in the above link, i.e. the dBpoweramp installer), that problem seems to not exist.
Conclusion: some change to the fdkaac CLI between versions 0.2.0 and 0.6.1 is causing dBpoweramp to break when reading AAC (m4a) bitrates of files encoded in VBR mode. Bitrate readings for CBR encodes are fine in both 0.2.0 and 0.6.1.
This seems more of a dBpoweramp bug than a fdkaac bug, since other tools (MediaInfo, foobar2000, etc..) give a correct reading for the bitrate of such VBR encoded files.
Last edited by Makaveli84; December 28, 2014, 08:57 AM.
Comment