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)
I noticed that this encoder produces 88.2 kHz .m4a files when the input is 44.1 and bitrate>=320kpbs. 48kHz remains untouched.
Is it a bug or a feature?
I noticed that this encoder produces 88.2 kHz .m4a files when the input is 44.1 and bitrate>=320kpbs. 48kHz remains untouched.
Is it a bug or a feature?
A little bit of both. One issue is that the configuration dialog currently has no idea what the input samplerate / channel count is going to be. And the encoder must be trying really hard to honor the bitrate request. I'll do a bit more checking on it - is it all bitrates >320kbps, even 324kbps? I'll check myself also.
is it all bitrates >320kbps, even 324kbps? I'll check myself also.
All bitrates >
= 320. Even 320 kbps. (2 channels, 16 bit).
By chance I noticed a serious encoding artifact (I'd actually describe it as a bug) when I tested this encoder with some gapless albums. The album is Transatlantic's The Whirlwind. I noticed that the track #4 (A Man Can Feel) has a suspicious track peak value of 2.46 after encoding it using the FhG AAC VBR preset 3. The track has a loud artifact in the left channel at about 2 min 1 s.
I tried to create a 30 s sample in which the artifact would occur at 25 s, but the cut source file did not produce the same artifact. Apparently only the complete track triggers it.
I verified the problem with two different computers.
I created samples of the reference file and the decoded file (decoded to float and cut). I reduced the volume levels by -8 dB to prevent clipping before I saved the samples in the 16-bit integer format. The artifact occurs at about 5 s.
The reference sample: [attachment=6589:A_Man_Ca...eference.flac]
The decoded sample: [attachment=6590:A_Man_Ca...oded_aac.flac]
Here is how the decoded sample looks in Audition:
(http://i224.photobucket.com/albums/dd212/AB2K/ha/winampfhgaacbug_waveform.png)
(http://i224.photobucket.com/albums/dd212/AB2K/ha/winampfhgaacbug_septral.jpg)
EDIT
benski and C.R.Helmrich, I have posted a PM to you.
I tried to create a 30 s sample in which the artifact would occur at 25 s, but the cut source file did not produce the same artifact. Apparently only the complete track triggers it.
Maybe removing first N*1024 samples will help?
So you think that the AAC frame border position may have an effect on this. That would be a logical explanation because I don't think a VBR encoder would take into account the past audio content from tens of seconds or minutes before the current frame.
That did the trick. I removed N*1024 samples from the beginning. Here is a ~15 s sample that produces the same artifact when encoded (using Winamp/FhG AAC v.1.01, VBR preset 3). The problem occurs at about 12.6 s. It is clearly audible when replay gain is set to prevent clipping.
[attachment=6591:A_Man_Can_Feel.flac]
Benski,
i wish you were posting this at the winamp forums!
By chance I noticed a serious encoding artifact (I'd actually describe it as a bug) when I tested this encoder with some gapless albums.
Thanks a lot, Alex, for this report! This is a very rare bug which has been fixed in a newer release of Fraunhofer's AAC encoder (version 03.02.03) a few weeks ago and should reach Winamp soon.
I noticed that this encoder produces 88.2 kHz .m4a files when the input is 44.1 and bitrate>=320kpbs. 48kHz remains untouched.
Is it a bug or a feature?
Thanks for reporting! It's a bug (because it was trivial to solve) and is also fixed in the new version.
Please, anyone, if you find such configuration problems or artifacts, report them here on HA along with the input file, just like Alex did, so we can reproduce and hopefully fix them.
Chris
@C.R.Helmrich
hi, do you plan to add adts support for VBR mode too?
_
@C.R.Helmrich
hi, do you plan to add adts support for VBR mode too?
_
The encoder supports VBR encoding in ADTS format. We (Winamp) have chosen not to implement it as there is no defined seek-table for ADTS files.
i hope you will reconsider...(may be as a silent option - for a CLI wrapper only!)...this would be very handy (with adts STDOUT support too! - may be as a silent option - for a CLI wrapper only!) for pipeing VBR/CBR aac from an audio decoder to an audio-video muxer...
_
sorry for OT...
_
I am looking forward to a fix for the upsampling issue. Regards.
Are you considering higher bitrate VBR presets? I use Q 0.9 with Nero which result in ~375 kbps with modern music and around ~250 kbps with older less hifi music. You (Fhg) have constant bitrate up to 448 kbps for us who want some reassurance headroom when it comes to the bitrate but a VBR mode that uses the highest bitrates and results in maybe 320-375 kbps would be much appreciated. Regards.
Are you considering higher bitrate VBR presets? I use Q 0.9 with Nero which result in ~375 kbps with modern music and around ~250 kbps with older less hifi music. You (Fhg) have constant bitrate up to 448 kbps for us who want some reassurance headroom ...
I assume you like the idea of headroom in order to avoid non-transparent encodings. Actually I tuned FhG's encoder for precisely that, using also the most "killer" items I could find here on HA. At the highest VBR mode, any item should be transparent. If it is not, please notify me. Until then, I see little point in adding a very-high-rate VBR mode.
In any case, you'd have to ask benski since he decides (and has to implement) which modes are/will be available in the Winamp GUI.
Chris
Am I correct to assume that the v. 03.02.03 is still not available?
Edit: Winamp 5.621 is still the latest build and its encoder version is 03.02.02. (at least in my installer, downloaded July 14)
Great! The only downside is I'm not using Winamp. Is therre a facet for foobar2k, or a plugin for f2k?
Am I correct to assume that the v. 03.02.03 is still not available?
Edit: Winamp 5.621 is still the latest build and its encoder version is 03.02.02. (at least in my installer, downloaded July 14)
Winamp 5.622 with FhG AAC 3.2.3 just got released moments ago.
Thanks for the info!
@benski can you update your attachement from the first post?
_
Apparently new version 3.2.3 has not only bug fixes but also quality tunings.
I assume you like the idea of headroom in order to avoid non-transparent encodings. Actually I tuned FhG's encoder for precisely that, using also the most "killer" items I could find here on HA. At the highest VBR mode, any item should be transparent. If it is not, please notify me. Until then, I see little point in adding a very-high-rate VBR mode.
In any case, you'd have to ask benski since he decides (and has to implement) which modes are/will be available in the Winamp GUI.
Chris
Depends on what you call "transparent".
The encoder is indeed very efficient and every detail is clear at the highest VBR mode, but the sound is still kinda "compact" and a bit unnatural compared to the lossless files.
320 kbps would be perhaps a bit overkill, but what speaks against a mode "6" at around 256 kbps?
Edit:
Sorry for the wrong quote I answered to at first!
can anybody help with the new .dll?
_
Download the latest Winamp package.
Depends on what you call "transparent".
The encoder is indeed very efficient and every detail is clear at the highest VBR mode, but the sound is still kinda "compact" and a bit unnatural compared to the lossless files.
Transparent here means indistinguishable from the original audio, i.e. failing a blind ABX test. Please provide a sample whose VBR 5 encoding sounds different to you, so I can try it myself. And if you haven't done so, please familiarize yourself with the ABX testing concept and the Terms of Services of this forum.
Chris
Igor, yes, I tried to reduce bit-rate variance a bit, as noted in a related thread (http://www.hydrogenaudio.org/forums/index....st&p=766941 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=89428&view=findpost&p=766941))
I have tried to get Winamp 5.562 standard, but I have legal problem with installation, probably its wrong build or beta release or wrong setup file :
setup inclides LGPL binaries libsndfile.dll and enc_lame.dll , but after installation I cannot find copy of LGPL license as text file (and information about where I can find source or patches for used lgpl libraries)
I was able successfuly download and install Winamp 5.562 lite version - looks like this file is legal (it didn't have LGPL parts, so it didn't have to ship copy of LGPL license text), but this edition didn't have FhG codec
please, add FhG codec dll as attach to this thread, so I can get this file from legal source
thanks
can anybody help with the new .dll?
please, add FhG codec dll as attach to this thread, so I can get this file from legal source
1. Download latest standard version (http://download.nullsoft.com/winamp/client/winamp5622_full_emusic-7plus_all.exe )
2. Extract downloaded installer with 7-Zip (NSIS installer)
3. encoder is in Plugins directory
I have tried to get Winamp 5.562 standard, but I have legal problem with installation, probably its wrong build or beta release or wrong setup file
[...]
please, add FhG codec dll as attach to this thread, so I can get this file from legal source
Even Winamp 5.562 lite (and enc_fhgaac itself!) uses libmp4v2.dll (Mozilla Public License):
3.6. Distribution of Executable Versions.
You may distribute Covered Code in Executable form only if the
requirements of Section 3.1-3.5 have been met for that Covered Code,
and if You include a notice stating that the Source Code version of
the Covered Code is available under the terms of this License,
including a description of how and where You have fulfilled the
obligations of Section 3.2.
So it seems that you'll have legal problems anyway
@Thundik81 thanks a lot...
_
Just curious, any chance to use this excellent codec with foobar or from command line? (without Winamp). I like this FhG thingy but dont want install Winamp just because of it.
easy, someone can reverse engineer it, though fraunhofer and this forum frowns upon that.
egad!
Just curious, any chance to use this excellent codec with foobar or from command line? (without Winamp). I like this FhG thingy but dont want install Winamp just because of it.
You mean like THIS (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6623) (thanks to nao (http://www.hydrogenaudio.org/forums/index.php?showtopic=89518&st=30) for creating it)
Thanks so much.
Just curious, any chance to use this excellent codec with foobar or from command line? (without Winamp). I like this FhG thingy but dont want install Winamp just because of it.
You mean like THIS (http://www.hydrogenaudio.org/forums/index.php?act=attach&type=post&id=6623) (thanks to nao (http://www.hydrogenaudio.org/forums/index.php?showtopic=89518&st=30) for creating it)
Does it work for Foobar, too?
why yes it does work with foobar
since i can't edit my previous post
--vbr 5 --ignorelength - %d
Hi,
I found channel mapping is incorrect for 4ch case.
From what I can see, resulting 4ch AAC has default channel layout in ISO spec (C L R Cs).
However, it seems L is mapped to C, R is mapped to L, and C is mapped to R.
(I don't know if it's winamp side or Fhg side problem).
--vbr 5 --ignorelength - %d
These parameters aren't working for me in Foobar. I'm getting " Conversion failed: The encoder has terminated prematurely with code 0 (0x00000000); please re-check parameters". Am I overlooking something obvious?
Hi,
I found channel mapping is incorrect for 4ch case.
From what I can see, resulting 4ch AAC has default channel layout in ISO spec (C L R Cs).
However, it seems L is mapped to C, R is mapped to L, and C is mapped to R.
(I don't know if it's winamp side or Fhg side problem).
It's a Winamp problem. There's not really good support at the moment for surround encoding. It's pending some API changes to make it work effectively.
It's a Winamp problem. There's not really good support at the moment for surround encoding. It's pending some API changes to make it work effectively.
Thanks. I noticed there's no way to specify channel layout in current Winamp plugin API;
Though 5ch, 5.1ch, and 7.1ch seemed to be fine.
--vbr 5 --ignorelength - %d
These parameters aren't working for me in Foobar. I'm getting " Conversion failed: The encoder has terminated prematurely with code 0 (0x00000000); please re-check parameters". Am I overlooking something obvious?
are these files all in the the same folder?
enc_fhgaac.dll
fhgaacenc.exe
libmp4v2.dll
libsndfile.dll
nsutil.dll
you'll find these in the winamp install folder
I've done a little ABX test with a trance track, using the FhG encoder. The results are not perfect but i think it's at least excluded that I was totally guessing all the time. Test log and a sample are included in the attachement...
Thanks a lot for testing, Gainless! Unfortunately I can't hear any artifacts on this item myself. Which kind of artifact(s) did you hear, and in which passage? And I assume you used the latest Winamp version?
Chris
For those who like numbers, I have quick dirty test results:
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%
lame 3.98.4* -V3 140s 13.22%
lame 3.99.1 -V3 160s 13.07%
musepack 1.30 -q5 114s 12.09%
musepack 1.16 -q5 114s 12.42%
neroaac 1.0.7.0 -q0.5 190s 12.18%
neroaac 1.5.4.0 -q0.5 146s 12.63%
ogg 2.83 lancer -q5 78s 12.10%
ogg 2.87 lancermod -q5 106s 12.01%
*iccpatch applied (test system: Athlon 64 2.0GHz, 2GB DDR, WinXp SP3)
Comments:
- I saw 96kbps test and was intrigued by Fhg AAC as I never dealt with before (although my test is in the safe/transparent range);
- I used nao's so I could bench on commandline with all codecs (enc_fhgaac.dll from Winamp 5.622 package)
- Couldn't get Fhg AAC into close range with other codecs, quite a jump between --vbr 4 and --vbr 5, and decimal values ignored
@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 (http://nyaochi.sakura.ne.jp/encoder-benchmark/result-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!
_
Thanks a lot for testing, Gainless! Unfortunately I can't hear any artifacts on this item myself. Which kind of artifact(s) did you hear, and in which passage? And I assume you used the latest Winamp version?
Chris
I also don't hear any obvious artifacts, the aac just sounds a bit different to the wav, that's all. I guess I had some kind of "lucky" day when I made the abx test in my previous post, because most of the time I don't get any good results (< 6-10%)...
If You don't listen the artifacts then it can be simply differences in the volume or time shifting.
It will be more safe to apply time shifting and gain to ABX sessions. Page 11 of http://www.rarewares.org/rja/ListeningTest.pdf (http://www.rarewares.org/rja/ListeningTest.pdf)
If You don't listen the artifacts then it can be simply differences in the volume or time shifting.
It will be more safe to apply time shifting and gain to ABX sessions. Page 11 of http://www.rarewares.org/rja/ListeningTest.pdf (http://www.rarewares.org/rja/ListeningTest.pdf)
I'm already using DSP on the ABX tests in Foobar, why shouldn't be that enough?
Foobar's ABX logs don't provide the information about DSP (Replaygain, etc.).
Your sample is ok. FhG LC-AAC doesn't put additional frames (delay) and volume is practically the same.
Foobar's ABX logs don't provide the information about DSP (Replaygain, etc.).
Your sample is ok. FhG LC-AAC doesn't put additional frames (delay) and volume is practically the same.
Fine, would have kinda sucked if I had to do it again
@ C.R. Heinrich
Will the encoder still be updated in the future, maybe with some more modes, or is this the final version?
Will the encoder still be updated in the future, maybe with some more modes, or is this the final version?
Quality-wise, we are not planning any huge updates, at least not for stereo and mono. But if there is a significant interest in other VBR modes, we will consider adding those.
P.S.: Helmrich, not Heinrich And you can call me Chris.
B66pak: Please keep in mind that MP3 is not AAC. And Fraunhofer's encoder is already faster than nero's, as Destroid posted. So I don't see the need to invest a lot of time in tuning our encoder for speed. In fact, we already did, so we won't be able to improve it by more than a few percent, I'd guess.
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:
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.
Btw, how much listenings do I need in an ABX test to make a proper judgement about the encoded material? I ever do around 10-15 ones, but that gives me weird results, e.g. 9/11 on the one and 2/11 on the other hand...
PS:
Sorry to Chris for the spelling mistake^^
@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
Btw, do you - or anyone else - have speed measurements for the iTunes encoder (via qaac or qtaacenc maybe)?
Chris
Intel Pentium G630 / 2x4Gb DDRIII-1333 / ImDisk 1.5.3 / Windows 7 Home Premium x64
neroAacEnc 1.5.4.0
-q 0.00 - 92,7x
-q 0.25 - 43,5x
-q 0.50 - 39,1x
-q 0.75 - 38,1x
-q 1.00 - 37,2x
qaac 1.04, CoreAudioToolbox 7.9.7.3
--tvbr 0 -q 2 - 45.9x
--tvbr 36 -q 2 - 40.3x
--tvbr 63 -q 2 - 36.6x
--tvbr 100 -q 2 - 35.0x
--tvbr 127 -q 2 - 33.9x
fhgaacenc 20111104, enc_fhgaac 1.02
--vbr 1 - 67,9x
--vbr 2 - 42,7x
--vbr 3 - 53,3x
--vbr 4 - 52,5x
--vbr 5 - 48,6x
no404error
Nice results.
Just some observations.
TVBR has no HE-AAC mode. It will be more correct to compare HE-AAC vs HE-AAC or LC-AAC vs LC-AAC.
Apple HE-AAC (--cvbr 64 --he) vs FhG HE-AAC (--vbr 2). Also qaac -q2 and -q1 has practicly identical quality. The difference isn't perceptible.
Thanks a lot, 404!
Also qaac -q2 and -q1 has practicly identical quality. The difference isn't perceptible.
Which setting was used in the last listening test? qtaacenc seems to default to -high, is that the same as -q 2 in qaac? And does nero automatically switch to HE-AAC for low -q values?
Chris
Which setting was used in the last listening test?
qtaacenc --highest (equivalent to qaac -q 2)
no404error
Nice results.
Just some observations.
TVBR has no HE-AAC mode.
I now. But I test 5 to 5 default profiles, Apple Core Audio AAC vs Fraunhofer AAC. FhG - winner.
TVBR has no HE-AAC mode. It will be more correct to compare HE-AAC vs HE-AAC or LC-AAC vs LC-AAC.
qaac 1.04, CoreAudioToolbox 7.9.7.3
Preset
Min (--tvbr 0) - -q 1/2 - 58.3x/45.9x
Low (--tvbr 32) - -q 1/2 - 54.2x/40.3x
Medium (--tvbr 64) - -q 1/2 - 48.9x/36.6x
High (--tvbr 96) - -q 1/2 - 46.5x/35.0x
Max (--tvbr 127) - -q 1/2 - 43.8x/33.9x
(--cvbr 64 --he) - -q 1/2 - 42.2x/36.1x
fhgaacenc 20111104, enc_fhgaac 1.02
Preset
--vbr 1 - 67,9x
--vbr 2 - 42,7x
--vbr 3 - 53,3x
--vbr 4 - 52,5x
--vbr 5 - 48,6x
Core Audio AAC HE mode is a spherical cow IMHO
Also qaac -q2 and -q1 has practicly identical quality. The difference isn't perceptible.
As I see, q1 has unacceptable higher bitrate than q2. Up to 5%
And does nero automatically switch to HE-AAC for low -q values?
-q 0.00-0.15 - HEv2
-q 0.16-0.30 - HEv1
-q 0.31-1.00 - LC
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:
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
But I test 5 to 5 default profiles
The thing is qaac's default is q2 and iTunes q1.
Apple Core Audio AAC vs Fraunhofer AAC. FhG - winner.
Winner for what? For speed or speed/quality/bitrate?
Sorry, I don't see how You've managed to make any conclusion.
I can add almost useless -q0 to LAME and claim that's it is slowest MP3 encoder and Helix is a winner (?).
Let's define the relations ( with acceptable level of precision): speed/quality/bitrate and then talk about winners.
What the goal of comparing fhg -v 3 and --tvbr 64 or 96 if these settings haven't even the same bitrate? Variation of all three variables gives us ....nothing.
Who does guarantee You that FhG is any better in quality terms or at least on par with tvbr -q0 at the same bitrate?
Winner for what? For speed or speed/quality/bitrate?
For speed. Only speed test at this time.
Who does guarantee You that FhG is any better in quality terms or at least on par with tvbr -q0 at the same bitrate?
My ears and... Your own Public AAC Listening Test Only samples with voice is important for me. FhG faster, cleaner and much hardware compatibility. Winner, at least only for me
FhG faster, cleaner and much hardware compatibility.
The hardware compatibility of all LC-AAC/HE-AAC encoders should be the same, since all implement the exact same specification. So the Fraunhofer encoder has no advantage here.
By the way, the Fraunhofer encoder in Winamp runs in "high quality" mode, which in case of VBR means the highest quality available. In "normal quality" mode, the encoder sounds slightly (maybe indistinguishably?) worse but is significantly faster. So comparing against QuickTime -q 2 is appropriate.
Anyway: thanks Destroid and (again) no404error for the analyses!
Chris
FhG faster, cleaner and much hardware compatibility.
The hardware compatibility of all LC-AAC/HE-AAC encoders should be the same, since all implement the exact same specification. So the Fraunhofer encoder has no advantage here.
By the way, the Fraunhofer encoder in Winamp runs in "high quality" mode, which in case of VBR means the highest quality available. In "normal quality" mode, the encoder sounds slightly (maybe indistinguishably?) worse but is significantly faster. So comparing against QuickTime -q 2 is appropriate.
Anyway: thanks Destroid and (again) no404error for the analyses!
Chris
Can you give us the command line for that quality switch?
Can you give us the command line for that quality switch?
Sorry, no. I didn't write enc_fhgaac.dll and the command-line wrapper. And to be clear: the command-line encoder you are talking about is neither developed nor supported nor endorsed by Fraunhofer (Fraunhofer sells its own command-line encoder which has dozens of switches, incl. quality). Nullsoft, in particular benski, have put the encoder and a lot of work into Winamp so that people like and use their software. So please appreciate that by using the encoder through Winamp.
Chris
By the way, the Fraunhofer encoder in Winamp runs in "high quality" mode, which in case of VBR means the highest quality available. In "normal quality" mode, the encoder sounds slightly (maybe indistinguishably?) worse but is significantly faster. So comparing against QuickTime -q 2 is appropriate.
I have to admit that I don't see any quality settings outside the VBR slider (kbps) Maybe it's totally hidden :shrug:
As for my QAAC results, the -q 2 setting was defaulted (quality 96) and of course lower -q settings were faster:
-q 2 (96) = 17.4x
-q 1 (64) = 24.7x
edit: doh! should have timed Fhg encoder via Winamp before posting
Test result: --vbr 4 = same speed as commandline
By the way, the Fraunhofer encoder in Winamp runs in "high quality" mode, which in case of VBR means the highest quality available. In "normal quality" mode, the encoder sounds slightly (maybe indistinguishably?) worse but is significantly faster. So comparing against QuickTime -q 2 is appropriate.
Chris,
There is no absolutely any information how changes the quality of Apple and FhG encoders with different speed settings.
Apple and FhG are totally different encoders and there is no parallel of Apple's -q2/q1 and FhG -high/normal quality.
There is already unfortunate myth in community of video compression that Xvid (MPEG4 ASP) is faster than x264. And it's simply not true. x264 with fast presets is still faster and better than XviD. Let's not create other myth.
P.S. Is speed still has any priority when CPUs are very fast and getting even more faster nowadays? At least it's not critical anymore.
Last time I've checked people preferred to squeeze the last few bits at cost of slower speed. http://www.hydrogenaudio.org/forums/index....c=58731&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=58731&hl=)
So please appreciate that by using the encoder through Winamp.
I do appreciate a lot. I still can't get that FhG (at least its particular Winamp's edition) encoder is available publicly. Thank You, Guys.
I have to admit that I don't see any quality settings outside the VBR slider (kbps) Maybe it's totally hidden :shrug:
P.S. Is speed still has any priority when CPUs are very fast and getting even more faster nowadays? At least it's not critical anymore.
Indeed. I think there's no speed slider in Winamp's AAC encoder because there's no need for it. There's no point in encoding faster=worse if at high quality you're still at least 40x faster than real-time.
Chris
On the other hand, Winamp Format Converter is still single-threaded. And if a user have 4-core CPU then Winamp encoder is quite slow compared with e.g. foobar2000 + 4 NeroAacEnc encoders in parallel.
There is a new version of Winamp with updated FhG AAC encoder 3.2.4
Last versions of FhG HE-AAC produce comparable bitrate at ~64 kbps as Apple HE-AAC encoder. So I've tried these encoder for set of samples. Won't go into details just will mention that FhG was quite better.
Good job indeed.
This makes the last public test at 64 kbps obsolete though (in less than one year).
There is a new version of Winamp with updated FhG AAC encoder 3.2.4
where?
_
http://forums.winamp.com/showthread.php?t=332010&page=3 (http://forums.winamp.com/showthread.php?t=332010&page=3)
Winamp 5.623 Released
First post has been updated accordingly.
Note that this is a forum exclusive (main site update on Monday 12th Dec).
Though all builds in all flavors & languages are up on the server, if you know the filenames...
Early Xmas present :-)
thanks a lot...
_
Last versions of FhG HE-AAC produce comparable bitrate at ~64 kbps as Apple HE-AAC encoder. So I've tried these encoder for set of samples. Won't go into details just will mention that FhG was quite better.
Good job indeed.
Thanks By "last versions", do you mean 3.2.3 and later? Were the average bit-rates of version 3.2.2 (the one of the 96-kb test) higher or lower than those of the Apple encoder on your test set at ~64 kb?
Chris
I'm not a good, trained listener like the guys here, but I think FhG encoder VBR preset 2 is very good, too.
I've had an impression that QuickTime tends to move spatial locations of the sound for lower bitrate setting (sound at slightly off from center is encoded into dead center). For this reason, QuickTime AAC is sometimes too easily ABX-able only by spatial information change, even for poor listener like me.
Though I didn't tried much, FhG seems not suffering from this kind of problem.
[attachment=6785:11_Homicide_5sec.flac]
Uploaded a sample to show the effect I wrote in the last post (though this is not a special example at all).
Try with qaac --he.
By "last versions", do you mean 3.2.3 and later?
Yep
Were the average bit-rates of version 3.2.2 (the one of the 96-kb test) higher or lower than those of the Apple encoder on your test set at ~64 kb?
It was 3.2.4 and bitrate was just slightly higher than of Apple (+0.4%) while FhG produces 65 kbps on my large set of albums and Apple 66 kbps.
3.2.2 produced around 70 kbps on average.
Maybe it's not the appropriate topic, but can we get an estimate when the FhG AAC encoder in Winamp will support HD-AAC encoding?
Btw, the VBR Preset 2 setting sounds really good considering that this is an AAC+ with SBR which i don't really like Although i've only listened to it through my amplifier yet. This way AAC+ always gives better result than listening to it using my phone. SBR's problems gets magnified with headphones by me.
Looks like i've killed this topic aswell.
Looks like i've killed this topic aswell.
Don't worry, you didn't. It's just that I (or we) can't answer this question at the moment. And thanks for your verdict of VBR mode 2!
Thanks, Igor! Then I'll leave the bit-rate tuning as it is.
Chris
Looks like i've killed this topic aswell.
Don't worry, you didn't. It's just that I (or we) can't answer this question at the moment. And thanks for your verdict of VBR mode 2!
Oh, i see Sorry, just really like to test HD-AAC and keep asking it everywhere nowadays.
About the VBR2 thing: i've tested it today while walking to work. With headphones SBR artifacts are easily noticable (especially where it adds sinusoids to the replicate content, or it missuses high volume noise in a band to replicate a complex waveform). However it's not that bad as i've expected. Maybe some tuning can be made to hide these annoying artifacts (i think it would be still better to replace complex waveform with some low level noise than encode a loud artifact which has nothing to do with the original waveform). I wish i could understand the complex algorithms behind HE-AAC so i can do some tune on my own. Maybe one day, i'm a programmer so there's hope
Thanks, Igor! Then I'll leave the bit-rate tuning as it is.
Chris
Is it maybe possible to do some improvement on the high frequencies?
I've tested a sample with hi-hats on VBR mode 2 and the difference is really obvious...
Is it maybe possible to do some improvement on the high frequencies?
I've tested a sample with hi-hats on VBR mode 2 and the difference is really obvious...
Probably not. As darkbyte mentioned, VBR 1 and 2 use SBR on the high frequencies, which is a parametric coding tool. Although it can get very close to the high-frequency input signal in terms of quality, it never fully reaches transparency in these frequencies. But you save quite a lot of bitrate. You can hear for yourself what it sounds like without SBR by choosing "AAC-LC Constant Bit Rate" encoding at 64 or 68 kbps in Winamp.
An SBR encoder is a quite complicated thing, darkbyte But we'll check whether some fine-tunings are still possible.
Chris
Is there a way to encode using FhG AAC codec out of Winamp? I mean, a command line encoder or something.
I'm interested in testing/comparing it but not very keen on installing third party software though.
EDIT: Sorry, just read this.
And to be clear: the command-line encoder you are talking about is neither developed nor supported nor endorsed by Fraunhofer (Fraunhofer sells its own command-line encoder which has dozens of switches, incl. quality). Nullsoft, in particular benski, have put the encoder and a lot of work into Winamp so that people like and use their software. So please appreciate that by using the encoder through Winamp.
I may not totally approve this in terms of compatibility but, anyway, codec can be used for free.
yes (https://github.com/tmkk/fhgaacenc)
I may not totally approve this in terms of compatibility but, anyway, codec can be used for free.
EULA:
3. RESTRICTIONS ON USE. Licensee may not: (i) modify or create any derivative works of the Software
so, if you follow terms - you cannot use this codec at all, because winamp itself have unresolved lgpl licensing problems described on second page of this thread
EULA:
3. RESTRICTIONS ON USE. Licensee may not: (i) modify or create any derivative works of the Software
'for free' stands for the price. I mean, free as in 'free beer', not as in 'free speech'.
(Apple and FhG are pretty much the same this way. Nero, not that much.)
I didn't came here to start any flame war, anyway.
Is it necessary to use the --ignorelength command when encoding with Foobar? Could it do any harm if it's used, slower speed perhaps?
I've read the description, but I'm not familiar with the technicalities, so I'm not sure how it applies to practical usage. (I encode mostly from FLAC, BTW.)
It is a good idea, since foobar2000 outputs UINT_MAX for the length fields, which will probably be processed wrong.
Thanks.
One thing I noticed is that when converting with Foobar the files are a tiny bit larger than when converting with Winamp. The difference is less than 0.01 MB for a track and it varies.
I used this command in Foobar:
--vbr 4 --ignorelength - %d
(I also tried without --ignorelength and it's the same as with it)
Is there a way to encode using FhG AAC codec out of Winamp? I mean, a command line encoder or something.
I'm interested in testing/comparing it but not very keen on installing third party software though.
EDIT: Sorry, just read this.
And to be clear: the command-line encoder you are talking about is neither developed nor supported nor endorsed by Fraunhofer (Fraunhofer sells its own command-line encoder which has dozens of switches, incl. quality). Nullsoft, in particular benski, have put the encoder and a lot of work into Winamp so that people like and use their software. So please appreciate that by using the encoder through Winamp.
I may not totally approve this in terms of compatibility but, anyway, codec can be used for free.
Its a shame thier product is so badly protected.
IsDebuggerPresent()? Give me a break.
I think I've found a new problem sample. The total ABX result is not that great, but after a reset I got a 9/10.
When you've downloaded the sample you'll notice a more or less subtle hi-hat after the kick starts. It sounded kinda off and harsh to me, which was the reason I started the test. I think there is already a difference when the kicks start, but I mainly focussed on the hi-hats that start at around 16 seconds and "respond" to the kicks. Everything was converted with the latest Winamp btw.
Someone may do a re-test?
Edit:
Forgot to mention it, the sample is encoded with the VBR 5 mode.
...the hi-hats that start at around 16 seconds and "respond" to the kicks.
These are quite tough for an encoder, since they are actually composed of many extremely short clicks. See spectrogram of the first of those hi-hats in the FLAC file. However, the encoder preserves them very well, except for above 16 kHz or so.
[attachment=6829:hush_mail_hihat.png]
I've ABXed the sample. Even if you disregard the last vote (I got tired), I'm still hovering around 20% guessing, so no significant ABX from me.
foo_abx 1.3.4 report
foobar2000 v1.1.10
2012/01/14 13:37:16
File A: C:\Unrar\Infected Mushroom - Hush Mail (sample).flac
File B: C:\Unrar\Infected Mushroom - Hush Mail (sample).m4a
13:37:16 : Test started.
13:39:17 : 01/01 50.0%
13:40:05 : 02/02 25.0%
13:41:07 : 02/03 50.0%
13:42:38 : 03/04 31.3%
13:43:43 : 04/05 18.8%
13:46:05 : 05/06 10.9%
13:47:38 : 06/07 6.3%
13:49:42 : 06/08 14.5%
13:50:07 : 06/09 25.4%
13:51:17 : 06/10 37.7%
13:53:18 : 07/11 27.4%
13:53:49 : 08/12 19.4%
13:54:44 : 08/13 29.1%
13:54:51 : Test finished.
----------
Total: 8/13 (29.1%)
Chris
...the hi-hats that start at around 16 seconds and "respond" to the kicks.
These are quite tough for an encoder, since they are actually composed of many extremely short clicks. See spectrogram of the first of those hi-hats in the FLAC file. However, the encoder preserves them very well, except for above 16 kHz or so.
[attachment=6829:hush_mail_hihat.png]
I've ABXed the sample. Even if you disregard the last vote (I got tired), I'm still hovering around 20% guessing, so no significant ABX from me.
Chris
Thanks for your effort, Chris!
What do you think, is there any room for improvement on this issue (if you can call it like that)?
Thanks for your effort, Chris!
What do you think, is there any room for improvement on this issue (if you can call it like that)?
Other than pumping more bits into high frequencies at VBR 5, no. I'll think about it. In the meantime, would you mind listening to the attached file at normal listening level (i.e. the same volume as during casual listening to music) and tell me how many tone pulses you can hear?
[attachment=6830:hf_test44.wav]
Chris
Thanks for your effort, Chris!
What do you think, is there any room for improvement on this issue (if you can call it like that)?
Other than pumping more bits into high frequencies at VBR 5, no. I'll think about it. In the meantime, would you mind listening to the attached file at normal listening level (i.e. the same volume as during casual listening to music) and tell me how many tone pulses you can hear?
[attachment=6830:hf_test44.wav]
Chris
The first one is pretty clear, the second one is already very quiet, and after that I hear nothing at all.
I guess that's not really good, isn't it?
The first one is pretty clear, the second one is already very quiet, and after that I hear nothing at all.
I guess that's not really good, isn't it?
That's a common misconception here on HA. You listened at normal levels (i.e. not cranking up the volume), so your performance is perfectly normal, maybe even above average for your age. At normal levels I get the same result as you. Bottom line: you might have heard artifacts below 16 kHz, so I'm not going to put more bits into high frequencies.
Is this "issue" a show-stopper for you? Apparently this was very hard to ABX. Can you live with the encoder's current performance on this item? Or are you really looking for utmost transparency?
Chris
The first one is pretty clear, the second one is already very quiet, and after that I hear nothing at all.
I guess that's not really good, isn't it?
That's a common misconception here on HA. You listened at normal levels (i.e. not cranking up the volume), so your performance is perfectly normal, maybe even above average for your age. At normal levels I get the same result as you. Bottom line: you might have heard artifacts below 16 kHz, so I'm not going to put more bits into high frequencies.
Is this "issue" a show-stopper for you? Apparently this was very hard to ABX. Can you live with the encoder's current performance on this item? Or are you really looking for utmost transparency?
Chris
Good question. I'm a kind of lossless-junkie so I would more tend to "yes", but of course these kind of issues don't turn the encoder to "completely awful" for me. So in conclusion it would be cool if it got "fixed" as it would make the encoder pretty flawless, but I wouldn't throw Winamp off the computer if not.
Gainless,
It would makes sense to see how other AAC encoders perform on this sample to see if it's quite normal behavior for the entire AAC format or it's only one particular encoder.
Let say to see how perform Apple and Nero. Previously Replaygain should be applied for Apple encoder (or to all encoders as well) as it changes volume noticeably.
Gainless,
It would makes sense to see how other AAC encoders perform on this sample to see if it's quite normal behavior for the entire AAC format or it's only one particular encoder.
Let say to see how perform Apple and Nero. Previously Replaygain should be applied for Apple encoder (or to all encoders as well) as it changes volume noticeably.
Judging from the ABX'ing I've done yet it's even more noticeable with Quicktime AAC at TVBR 95 (has 13 kbps less on average though), but can't prove it already, I'll upload a log later.
Then it's not only FhG.
Can You try CVBR, Nero and FhG all together in ABC/HR? With this http://ff123.net/abchr/abchr.html (http://ff123.net/abchr/abchr.html)
Then it's not only FhG.
Can You try CVBR, Nero and FhG all together in ABC/HR? With this http://ff123.net/abchr/abchr.html (http://ff123.net/abchr/abchr.html)
Should be no problem at all, but this will take very long with at least 30 listenings. Btw, have you already tried to ABX the sample? It would be great to hear some other views on it.
Btw, have you already tried to ABX the sample? It would be great to hear some other views on it.
Sorry, I have no time right now. Will try it later. I mention the ABC/HR because it can be useful for Chris to see if there is any other AAC encoder that can handle this sample better, hence there will be still room for improvement.
Where can I find a list of available parameters that can be used with this FhG AAC encoder?
I'm looking for a parameter that would allow me to automatically create a "Tool" tag for each file being converted with FhG. This "Tool" tag just needs to say "FhG AAC version x.x.x.x" so that I know what encoder was used to create a particular file. Nero and LAME (and probably many other encoders) add this tag by default.
Thanks!
Fraunhofer's AAC encoder does not add such a "tool" tag at the moment, and I don't think Winamp offers a switch for this either. But I'll keep in mind that there's interest in such metadata.
Chris
Thank you, Chris!
Fraunhofer's AAC encoder does not add such a "tool" tag at the moment, and I don't think Winamp offers a switch for this either. But I'll keep in mind that there's interest in such metadata.
Chris
Yes, this would be really nice. Although I would like to see in addition to the encoder and version, the parametres used to create the file, just like Nero AAC and Quicktime does.
I should be able to add this in the next version.
Hey,
Late to the party here... I have 2 questions about this DLL:
1) Is there any API documentation anywhere?
2) Is there a 64-bit version somewhere?
(I've emailed FHG licensing too)
They got back to me that licensing their object code would be "about the price of an expensive car. Still interested?". That's kind of a dick answer hey? I was requesting specifics.
Little update for my ABXing claims:
I don't really know why, but the more I ABX, the worse results I get. I've tried the sample with Nero, Quicktime and FhG today again, and couldn't achieve anything far below 50%. Seems like the difference to the lossy files is not significant enough to be noticeable for me anymore. I'll try it later again, but I'm not too optimistic to get better results...
Quality-wise, we are not planning any huge updates, at least not for stereo and mono. But if there is a significant interest in other VBR modes, we will consider adding those.
Certainly yes. Different people will have a different threshold of bitrate and quality, due to most different reasons. May it be just to "feel safe". Your quality steps are quite coarse, so there may be people (like me) who feel like VBR preset 5 "wasting size", but preset 4 "sparing quality".
As an example, one may compare with other formats, like MP3 or Ogg Vorbis: MP3 should have around 192 kbps, preferably VBR (e.g. lame -V 2), and because it is less efficient than the current generation of encoding algorithms, AAC with a comparable quality may need only 75-80% of the MP3 bitrate, or about the same as Ogg Vorbis at -q 5, so the target for a VBR AAC encode would possibly be around 160 kbps.
QuickTime uses discrete steps too, but they are finer. Their --tvbr [<=]91 seems to be similar to your --vbr 5, but the next lower step, --tvbr [<=]82, appears to give results quite close to oggenc2 -q 5 or ~80% of lame -V 2.
Quality-wise, we are not planning any huge updates, at least not for stereo and mono. But if there is a significant interest in other VBR modes, we will consider adding those.
Certainly yes. Different people will have a different threshold of bitrate and quality, due to most different reasons. May it be just to "feel safe". Your quality steps are quite coarse, so there may be people (like me) who feel like VBR preset 5 "wasting size", but preset 4 "sparing quality".
As mentioned here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=95121&view=findpost&p=799846), it seems Winamp 5.63 has been released (http://forums.winamp.com/showthread.php?t=345684), with an updated AAC encoder version which now includes a VBR mode 6 (roughly 256 kbit/s stereo on average). VBR mode 5 should now have a slightly lower average bit-rate than in older versions (closer to 192 kbit/s stereo).
Chris
New: [enc_vorbis] Ogg Vorbis Encoder (based on aoTuV)
I like this!
As mentioned here (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=95121&view=findpost&p=799846), it seems Winamp 5.63 has been released (http://forums.winamp.com/showthread.php?t=345684), with an updated AAC encoder version which now includes a VBR mode 6 (roughly 256 kbit/s stereo on average). VBR mode 5 should now have a slightly lower average bit-rate than in older versions (closer to 192 kbit/s stereo).
Okay, but...
The gap between mode 4 (~128 kbps) and 5 (~192 kbps) is too large for my taste. I'm hoping for a mode 4.5 (~160 kbps).
Is this (https://github.com/mstorsjo/fdk-aac) the same implementation as is used in Winamp?
Fraunhofer FDK AAC code from Android.
Any news about HD-AAC encoding? Are Winamp devs still considering to adding it or they dropped it because of the lack of interest?
Sorry to resurrect this old thread, but according to Winamp 5.63 version log, FhG AAC is 3.2.4, whereas at the encoder settings window in Winamp, it says FhG 3.02.11. Previous versions had matching log and "inside" version info (i.e. 3.2.2 vs 3.02.02 and 3.2.3 vs 3.02.03).
Any idea why is that and what does it mean?
Sorry to resurrect this old thread, but according to Winamp 5.63 version log, FhG AAC is 3.2.4, whereas at the encoder settings window in Winamp, it says FhG 3.02.11.
Maybe Chris can answer this.
My recent encodes show: "Tool fhgaac v03.02.11;VBR=5" and I was under the impression this was the latest version
Winamp 5.623 [Dec 9 2011]
* Updated: [enc_fhgaac] Fraunhofer AAC Encoder v3.2.4
My recent encodes show: "Tool fhgaac v03.02.11;VBR=5" and I was under the impression this was the latest version
Jup, that's what's in Winamp version 5.63. V03.02.04 was contained in Winamp 5.623, like lvqcl wrote.
Chris
My recent encodes show: "Tool fhgaac v03.02.11;VBR=5" and I was under the impression this was the latest version
Jup, that's what's in Winamp version 5.63. V03.02.04 was contained in Winamp 5.623, like lvqcl wrote.
Chris
Winamp 5.63 [Jun 28 2012]
* New: Hungarian and Indonesian installer translations and language packs
* New: [enc_vorbis] Ogg Vorbis Encoder (based on aoTuV)
* Improved: Shift+F10 app key support in the Media Library
* Improved: [enc_fhgaac] Added VBR mode 6, plus other minor quality improvements
* Improved: [in_flac] Producer metadata support
* Improved: [in_mod] Refactored, simplified and threadsafe memory allocation
* Improved: [ml_history] Save playcounts when updated instead of only on exit
* Improved: [ml_local] Increased search query buffers from 512 or 1024 to 2048 bytes
* Improved: [gen_hotkeys] Added manual advance and visualization specific actions
* Fixed: Embedded album art not working in some scenarios
* Fixed: Video window reopening after being closed when editing mp4 tags
* Fixed: [aacdec] Memory leak when re-syncing to AAC stream
* Fixed: [bmp] Bounds checking in TSCC decoder
* Fixed: [bmp] Heap overflow issues (thanks: Secunia)
* Fixed: [in_avi] Divide-by-zero and NULL pointer issues (thanks: FuzzMyApp)
* Fixed: [in_mod] .IT memory & heap corruption issues (thanks: Jeremy Brown, MSVR)
* Fixed: [ml_local] Crash in MLDBAPI::SetField cache
* Fixed: [pmp_android/usb] Genre and Year metadata edits writing to Disc# field
* Fixed: [vis_milk2] Presets not reacting to music in localized installs (Milkdrop v2.25)
* Misc: More general tweaks, improvements, fixes and optimizations
* Updated: [aacdec] Fraunhofer AAC Decoder v1.762.208
* Updated: [in_vorbis] libogg 1.3.0 & libvorbis 1.3.3
* Updated: [lame_enc] LAME 3.99.5
* Updated: [png] libpng v1.5.10
* Updated: [vp8] libvpx v1.1.0
* Updated: [xml] expat v2.1.0
* Updated: [zlib.dll] zlib 1.2.7
Winamp 5.623 [Dec 9 2011]
* Fixed: mp3 decoding errors at end of file (should fix reported CD burning errors)
* Fixed: [aacdec] Detection of parametric stereo for AAC files made with older encoders
* Fixed: [enc_fhgaac] MP4 encoder not always closing on errors or aborted transfers
* Fixed: [in_avi] Crashing with certain malformed AVI files
* Fixed: [in_flac & in_mp4] Memory leaks
* Fixed: [in_mod] Bounds check for comments parsing
* Fixed: [pmp] Multithreaded race condition (now supports thread-safe transfers)
* Fixed: [pmp_android] Embedded album art being deleted on transfers
* Misc: More general tweaks, improvements, fixes and optimizations
* Updated: [enc_fhgaac] Fraunhofer AAC Encoder v3.2.4
* Updated: [gen_jumpex] JTFE v1.2.5
I think the missing "Updated enc_fhgaac..." line in the 5.63 version info mislead me to thinking that 5.63 was still using 3.2.4 (though it said it was upgraded and improved, so even more confusing). Anyways, 5.63 has 3.2.11 and that's that. Thanks for your answers.
Sorry to resurrect this old thread, but according to Winamp 5.63 version log, FhG AAC is 3.2.4, whereas at the encoder settings window in Winamp, it says FhG 3.02.11.
Maybe Chris can answer this.
My recent encodes show: "Tool fhgaac v03.02.11;VBR=5" and I was under the impression this was the latest version
How do you get this metadata?
I encode with Winamp and check for meta with MediaInfo, mp3Tag and dbpoweramp looking for encoder version and settings, but I never see any. I actually remember someone requesting this functionality to be added to the fhg encoder. So is this something new with winamp 5.63/fhg 3.2.11 or what?
Sorry to resurrect this old thread, but according to Winamp 5.63 version log, FhG AAC is 3.2.4, whereas at the encoder settings window in Winamp, it says FhG 3.02.11.
Maybe Chris can answer this.
My recent encodes show: "Tool fhgaac v03.02.11;VBR=5" and I was under the impression this was the latest version
How do you get this metadata?
I encode with Winamp and check for meta with MediaInfo, mp3Tag and dbpoweramp looking for encoder version and settings, but I never see any. I actually remember someone requesting this functionality to be added to the fhg encoder. So is this something new with winamp 5.63/fhg 3.2.11 or what?
Its an update in the latest Winamp 5.7 Beta found here.
http://forums.winamp.com/showthread.php?p=...888#post2916888 (http://forums.winamp.com/showthread.php?p=2916888#post2916888)