Winamp FhG AAC encoder with gapless fix, Updates from the 5.62 release Options

[benski]

Steve from the AAC listening test topic found a bug related to gapless information in m4a files encoded with Winamp/FhG's new AAC encoder.

Updates from the 5.62 release
* Fixed a bug that was preventing gapless playback information from being written to the encoded file in some circumstances
* Fixed compatibility issue that was preventing HE-AAC files from being used with iTunes
* Fixed a bug that was causing the ADTS encoder to fail with the default settings

To install, just unzip this to your Winamp plugins folder. It should overwrite an existing file (unless you are using an older version of Winamp).

This will be released with 5.63 (or 5.621 depending on what version number we decide upon)

Attached File(s)

 enc_fhgaac_v1_01.zip ( 434.58K ) Number of downloads: 854

 

[b66pak]

@C.R.Helmrich do you have any plans for increasing the encoding speed?

looking at this http://nyaochi.sakura.ne.jp/encoder-benchm...t-20061103.html

i can see that another fraunhofer tool (the mp3 encoder) is king of the speed...

so you have a very high standard for encoding speed to keep!
_

This post has been edited by b66pak: Nov 9 2011, 19:49

[Destroid]

i can see that another fraunhofer tool (the mp3 encoder) is king of the speed...

Ah, the Fraunhofer MP3 Surround encoder. Actually that test in b66pak's link was CBR 128kbps. But here is its VBR results with the relevant contenders/affiliates:

CODE

fhg aac 3.2.3      --vbr 4   115s   10.10%
fhg aac 3.2.3      --vbr 5   125s   15.60%
helix mp3 5.1      -V120      29s   13.68%
fhg mp3s enc 1.5   -m 2       34s   13.65%

Comments:
- the "Process time" of the Fhg MP3 surround encoder was the same after ICCpatch-ing the executable, although the global times differed (obviously the unpatched time was slower)
- on this system the Helix encoder prevailed (for those wanting to know, material tested was hard rock CD from 1997 with total running time of 46m43s)

@C.R.Heineken - I wanted to ask inquire into the possibility of a preset between --vbr 4 and --vbr 5. I think --vbr 4 is a good preset for about average 130kbps, but the jump to > 200kbps with --vbr 5 seems a bit overkill, but I don't have any reason to doubt it's well tuned.

[C.R.Helmrich]

@C.R.Heineken - I wanted to ask inquire into the possibility of a preset between --vbr 4 and --vbr 5. I think --vbr 4 is a good preset for about average 130kbps, but the jump to > 200kbps with --vbr 5 seems a bit overkill.

True. Yes, as said, it's a possibility. I'll keep it in mind. Btw, do you - or anyone else - have speed measurements for the iTunes encoder (via qaac or qtaacenc maybe)?

Chris

[Destroid]

Btw, do you - or anyone else - have speed measurements for the iTunes encoder (via qaac or qtaacenc maybe)?

Finally got the hang of QAAC+[Apple Application Support] but doesn't reveal much else already posted (thanks no404error for the fast results), so figured I'd at least throw in FAAC results too:

CODE

fhg aac 3.2.3       --vbr 4   115s   10.10%
fhg aac 3.2.3       --vbr 5   125s   15.60%
neroaac 1.0.7.0       -q0.5   190s   12.18%
neroaac 1.5.4.0       -q0.5   146s   12.63%
qaac 1.04*       --cvbr 170   158s   11.78%
qaac 1.04*        --tvbr 82   159s   11.58%
qaac 1.04*        --tvbr 91   160s   14.12%
faac 1.28 mod -b170 -c19600   174s   12.04%
faac 1.28 mod         -q130   172s   11.67%

*QT 7.7.1 CoreAudioToolbox 7.9.7.8

Comments:
- all tests were on same machine with same material, however prior tested codecs' results are copy+pasted to this table
- Apple TVBR also has gaps in the scale (i.e. no stop points between --tvbr 82 and --tvbr 91)
- FAAC ABR 170 defaulted to 20000Hz bandwidth so I lowered it to 19600 (same bandwidth as FAAC -q130)
- at first glance FAAC ABR appeared not to "flex" much but closer examination revealed bitrate rapidly fluctuates 150-210kbps