Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Unexpected behavior in FhG AAC encoder (Read 25948 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Unexpected behavior in FhG AAC encoder

Used:
- Foobar 2000 1.1.7
- enc_fhgaac.dll from Winamp 5.63 (tested settings VBR 3 / VBR 4)
- fhgaacenc.exe (20120624)

When converting a 32-bit float WAV file, if one channel becomes too quiet the resulting encode sounds like it's damaged. In my situation the problem occurs when left channel volume is between -18 to -19 dB while the right channel volume is between -125 to -130 dB. Obviously converting the WAV to 16-bit beforehand solves the problem, but that is a step I had not needed previously.

At first Winamp 5.63 'Format Converter' had the same garbled output but when I changed VBR settings the issue inexplicably ceased even after setting back to VBR 3  which I find even stranger.

If I had to guess, it appears the encoder is trying to juggle mid-side encoding and 'silence-encoding' (when it drops below 4kbps) :shrug:, something very unlikely to occur on CD material.
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #1
To simplify things for me, could you upload the original 32-bit WAV and the "buggy" MP4/M4A file please?

So does the louder channel also sound damaged, or only the quieter?

Chris
If I don't reply to your reply, it means I agree with you.

Unexpected behavior in FhG AAC encoder

Reply #2
It just sounds like the file sustained damage. Depending on the decoder it either squelches and/or skips the affected area, or, stutters a little and continues play the rest of the file one octave lower.

Where shall I upload my audio clips?

edit: I am going to open a topic in "Uploads" section. Also, I should have said, "...continues to play the rest of the file one octave slower."
"Something bothering you, Mister Spock?"


Unexpected behavior in FhG AAC encoder

Reply #4
Didn't test yet but why don't you try again with the latest FhG's DLLs and the latest foobar2000 (don't think this will change anything).

Unexpected behavior in FhG AAC encoder

Reply #5
No need to, I could already reproduce it. The encoder runs through, but the produced bitstream has some invalid frames starting at 6.5s.

Thanks for the report, Destroid, I'll take a look at this at work.

Chris
If I don't reply to your reply, it means I agree with you.

Unexpected behavior in FhG AAC encoder

Reply #6
Ah, that was fast. Anyway, I was almost sure updated software would not help,but I just retested with FB2K 1.2.8 and enc_fhgaac.dll from Winamp 5.70b3417. Same result.

I also noticed 'Highest BPS mode supported' was set to 24-bits. I changed to 16-bits it seemed to remove the worst of the side-effect. I wonder if Winamp's 'Format Convert' did a bitrate conversion in the background when I changed settings but I could not replicate.

Glad to participate, HA ppl
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #7
Ah, that was fast. Anyway, I was almost sure updated software would not help,but I just retested with FB2K 1.2.8 and enc_fhgaac.dll from Winamp 5.70b3417. Same result.

I also noticed 'Highest BPS mode supported' was set to 24-bits. I changed to 16-bits it seemed to remove the worst of the side-effect. I wonder if Winamp's 'Format Convert' did a bitrate conversion in the background when I changed settings but I could not replicate.

Glad to participate, HA ppl



New Winamp 5.7 Beta, build 3435 (with Winamp Cloud Beta)
Updated: [enc_fhgaac] Fraunhofer AAC Encoder v3.02.15

Maybe this fixes the problem?

Unexpected behavior in FhG AAC encoder

Reply #8
New Winamp 5.7 Beta, build 3435 (with Winamp Cloud Beta)
Updated: [enc_fhgaac] Fraunhofer AAC Encoder v3.02.15

Maybe this fixes the problem?

Not yet, issue still exists. TBH I hadn't expected a quick fix anyway.

Shortly after I started this thread I tested several different other AAC, MP3 and lossy encoders, yet none of them exhibited the issue. My discovery of this bug with enc_fhgaac was blind luck since most users are unlikely to be working with resolutions above 16 bits where large differences in amplitude occur between channels (specifically when only one channel's signal is less than -112dB or whatever value of the threshold that is tripping up enc_fhgaac).
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #9
Indeed, we just finished a 03.02.16 release which fixes this issue, but of course this hasn't made it into Winamp yet.

Anyway fyi, even with 03.02.15 and earlier, VBR modes 1 and 6 (and the bit-rate-requivalent CBR modes) are not affected by the bug.

By the way, 03.02.15 includes some speed optimizations, so I'd be curious how much speed improvement you get for the VBR modes with the latest Winamp 5.65 over 5.63. On my old dual-core Athlon X2 it was between 10 and 20%.

Chris
If I don't reply to your reply, it means I agree with you.

Unexpected behavior in FhG AAC encoder

Reply #10
Chris,

Do You tune quality of  your encoder or it's a bug fixes?

Thank You.

Unexpected behavior in FhG AAC encoder

Reply #11
Anyway fyi, even with 03.02.15 and earlier, VBR modes 1 and 6 (and the bit-rate-requivalent CBR modes) are not affected by the bug.
I had not thought of trying CBR. Although it is not much of an excuse, my portable player does not mind VBR AAC in contrast to its inability to correctly handle VBR MP3.

By the way, 03.02.15 includes some speed optimizations, so I'd be curious how much speed improvement you get for the VBR modes with the latest Winamp 5.65 over 5.63. On my old dual-core Athlon X2 it was between 10 and 20%.
I ran a quick test on one CD album using --vbr 3 and the results are notable (Athlon64 3000+):
v5.63 = 28.04x, ave 116kbps
v5.65 = 34.50x, ave 114kbps

Nice!
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #12
23%, nice indeed. Thanks for testing.

Igor, during the last year, only bugfixes and speed-ups, and slight reduction in bit-stream size sometimes, esp. for loud music (see Destroid's last post, must be rock music?). Quality is probably the same.

Chris
If I don't reply to your reply, it means I agree with you.

Unexpected behavior in FhG AAC encoder

Reply #13
Indeed, you have correctly guessed the genre. That particular album was somewhat dynamically compressed although not as horribly as other albums with RG -10dB or more. (Or is it less when its even louder?  )

I also want to apologize for misreading your post about VBR modes 1 & 6 not having the bug. I also did not test those settings either for the same reason that I was putting music on a portable but needed neither ultra-quality nor low-bitrate since most of the tracks I listen to are work-in-progress of home studio projects. (Imagine my shock when I heard that glitch in the encode and feared some part of my DAW was damaged  so I was glad it was a bug since software is more economically fix-able.  )
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #14
FhG tends to increase bitrate on rock music ... like Nero 

Unexpected behavior in FhG AAC encoder

Reply #15
Indeed, we just finished a 03.02.16 release which fixes this issue, but of course this hasn't made it into Winamp yet.

Anyway fyi, even with 03.02.15 and earlier, VBR modes 1 and 6 (and the bit-rate-requivalent CBR modes) are not affected by the bug.

By the way, 03.02.15 includes some speed optimizations, so I'd be curious how much speed improvement you get for the VBR modes with the latest Winamp 5.65 over 5.63. On my old dual-core Athlon X2 it was between 10 and 20%.

Chris

Chris, thanks for the fix. I don't even know if I should ask this but, could you upload the DLLs (enc_fhgaac.dll, libmp4v2.dll, nsutil.dll) so we can test before the new Winamp?

Thanks.

Unexpected behavior in FhG AAC encoder

Reply #16
will try to get the next beta build (though might be the one after that) to include the updated version of the FHG library. as it seems it wouldn't have been viable to include anyway at the time of v5.65 needing to be released.

Unexpected behavior in FhG AAC encoder

Reply #17
will try to get the next beta build (though might be the one after that) to include the updated version of the FHG library. as it seems it wouldn't have been viable to include anyway at the time of v5.65 needing to be released.

The current, latest beta (5.7 Beta 12, build 3437) doesn't have .16.

Unexpected behavior in FhG AAC encoder

Reply #18
will try to get the next beta build (though might be the one after that) to include the updated version of the FHG library. as it seems it wouldn't have been viable to include anyway at the time of v5.65 needing to be released.

Great, thanks. Yes, judging from the date the Winamp 5.65 installer mentions (July 23), it was impossible for us to finish our bugfix in time for that release. Is Winamp 5.7 the next release?

Sorry, eahm, no, those files are provided by the Winamp team, not us. Plus, to avoid having potentially buggy beta builds leaking around here, I'd prefer waiting for official Winamp builds.

Chris
If I don't reply to your reply, it means I agree with you.

Unexpected behavior in FhG AAC encoder

Reply #19
If I may...

I don't think the bug I reported really affects most conversion usage. It was my own dumb agenda to directly convert 32-bit float WAV/PCM to AAC (along with other rare circumstances) that tripped this error.

I think Winamp's Fhg encoder is very, very good and users should enjoy the great quality and the optimizations of version 03.02.15 (and please bring some more speed comparisons on more systems  ). Also, I do not have any 24/96 DVD-A material to test. I can say downsampling to 16-bits is a viable workaround for the time, and also  that I have not reproduced this except on this 1 track. (My main interest: "Why? Can I identify why?)

I appreciate the communication of the Winamp team and the HA users, even if my reported situation is more the exception than the rule.
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #20
I think Winamp's Fhg encoder is very, very good and users should enjoy the great quality and the optimizations of version 03.02.15

Been a long time Nero AAC user, then switched to QAAC (for true VBR mainly, though I can't say with certainty if quality is better, both are very good), so should I give this one a try? Sorry if I'm going a bit off-topic here...

Quote
I appreciate the communication of the Winamp team and the HA users, even if my reported situation is more the exception than the rule.

Me too, that's one of the great things about HA: the fluent communication between developers and users.

Unexpected behavior in FhG AAC encoder

Reply #21
Pardon the delay in responding. I would like to reference this 96 kbps AAC listening test.

I have always been impressed with HA's public listening tests and find them very credible due to the methodology being scientific rather than "warm fuzzy" feel-good. Anyway, the Fhg encoder from Winamp scores well in that test, as does QAAC, so when I got into portable players last year I went with the speedier encoder that delivered excellent results.

Why I was late getting into portable players? Let's just say I chose a non-violent alternative concerning an individual* at a public place of convening that had an internet jukebox, of which that individual escalated from annoying to belligerence.

* Internet jukebox fascist: one who monopolizes the machine with $10-$20 worth of selections and also kisses-up to the management to have others' selections skipped.
"Something bothering you, Mister Spock?"

Unexpected behavior in FhG AAC encoder

Reply #22
Pardon the delay in responding.

No apologies needed.

Quote
I would like to reference this 96 kbps AAC listening test.

Thanks for that link. I believe I had rushed through those results some time ago, looking at them in more detail I see I have nothing to worry about (not that I had worries anyway, but still it's nice to see it). I'll surely go on with QAAC, though if I feel adventurous i'll transcode some lossless files to Fhg and give it a try. That said, I'm really confident in my inability to discern such tied performances.

Quote
I have always been impressed with HA's public listening tests and find them very credible due to the methodology being scientific rather than "warm fuzzy" feel-good.

Indeed. I have always been impressed with the whole methodology here, as well as with the knowledge and willingness to help of most members.

Quote
when I got into portable players last year I went with the speedier encoder that delivered excellent results.

You mean speedier to encode into or speedier to decode from? The first is not really an issue for me (I'm young and can wait) but the second could matter more in the field of portable players.

Thank you very much, Destroid.

Unexpected behavior in FhG AAC encoder

Reply #23
The current, latest beta (5.7 Beta 12, build 3437) doesn't have .16.

that's because no one on our side knew about it like Chris mentions in his following response. plus i said we'd try to get it into the next beta build which i naively assumed would be understood that it's not present in any of the current builds available.

Winamp 5.7 the next release?

v5.7 is currently on a rolling beta release plan with 'full' versions being provided in the interim if there's enough to warrant a build (e.g. v5.64) or if there's enough of a critical issue and appropriate fixes (e.g v5.65).

Sorry, eahm, no, those files are provided by the Winamp team, not us. Plus, to avoid having potentially buggy beta builds leaking around here, I'd prefer waiting for official Winamp builds.

there'd just be buggy Winamp beta builds instead floating around

Unexpected behavior in FhG AAC encoder

Reply #24
Beta 13 still doesn't have .16.