Winamp FhG AAC problem on Sansa e250 v1

[ThaCrip]

I just noticed a moment ago that when i encode a 32kbps (or even higher bit rates like 64kbps etc) AAC file with the Winamp FhG encoder through Foobar2000 that when attempting to play back that audio file on my Sansa e250 v1 using Rockbox v3.14 that it basically causes super high CPU usage to where you can see it's really taxing the battery (like battery left level drops off a lot) etc, like plays for a little, pauses for a second or so (like it's loading more info), then keeps on doing that over and over and you basically have no control over input to the device at that point and i have to hold down the power button for a while to force the device to power off. then i can power it back on and everything works fine (like it's back to normal) except for audio files encoded with Winamp FhG AAC which always causes this issue (i tried it a handful of times or so so i know it's not a rare glitch but is consistent).

I assume this is a weird glitch on Rockbox? ; because Apple AAC (qaac.exe in Foobar2000) works fine but i avoid it because at lower bit rates it's much easier for me to ABX than the Winamp FhG encoder.

I can play MP3(encoded with LAME)/Apple AAC fine and even the recent Opus v1.2.1, which seems to be a bit more CPU intense, plays back fine to. but Winamp FhG AAC is not usable.

any suggestions?

p.s. those 32kbps Winamp FhG AAC file plays fine in Foobar2000 on my computer.

[saratoga]

Presumably those files are aac-he which requires a more powerful CPU than the e200v1 has. If you use aac-lc you won't have that problem.

[ThaCrip]

So in other words, in short... I can't use the Winamp FhG encoder, at least not at those really low bit rates.

but i did not realize that AAC was that CPU intensive at any bit rates. i am surprised that needs more CPU than Opus does being AAC is older. like with Opus i can tell it's using quite a bit of CPU especially when changing tracks or when fast forwarding you can see a decent delay before it resumes playback(or changes tracks) when you release the fast forward button etc but Opus is basically useable on my e200 series v1 unlike AAC-HE.

but if i understand correctly it appears that AAC-HE kicks in on low bit rates as around 96kbps or above(?) it uses the less CPU intensive stuff (AAC-LC). but if that's true it kinda defeats the purpose of using AAC as at that point you might as well use MP3 since it's light on resources and, as everyone already knows, once you get into the higher bit rates there is not all that much difference in sound quality between MP3/AAC etc and it makes the most sense to use MP3 at that point because everything supports it and minimal on CPU to which would basically mean best battery life. a little side note i think when ABXing a song i was testing on my Klipsch computer speakers last night once i hit LAME v4 (165kbps average) is my point of transparency but it seems like one person claimed that most people notice transparency with MP3 between the v2-v4 mods (190kbps/165kbps ranges)... "Many people find that somewhere between LAME -V2 and LAME -V4 is transparent, so you might want to start at -V2 and work downwards." (this was from a Nov 2010 post here... https://hydrogenaud.io/index.php/topic,84962.msg731389.html#msg731389 ). i have generally been using v2 to play it safe as i would imagine that's roughly the sweet spot for sound quality/file size for most people, give or take a little.

so it looks like ill probably just stick to MP3 for general use and occasionally try Opus or something. but it's a shame as that Winamp FhG sounds pretty good at 32kbps as i was considering using that for music i am not as concerned with for keeping top quality sound. i am not 100percent sure, but i think it's harder for me to ABX vs Opus at the 32kbps setting and being AAC is the standard outside of MP3 that basically makes it better then Opus in general due to widest support outside of MP3.

but thanks for your time as it appears what you said pretty much sums up my problem as i just never realized AAC, at any bit rates, would be a issue with CPU given the device is supposed to play MP3/AAC in general.

p.s. i do have a Zune 30GB but i prefer the Sansa because with Rockbox everything just works like it should with being able to browse stuff through a simple directory structure and then load it and load music onto the device like how it should be loaded with a simple copy/paste from windows explorer etc instead of being forced to use some extra software like with the Zune and even with that you can't browse the device directly etc. i have not tried those Winamp FhG encoder files on the Zune 30GB yet but i likely won't bother especially if there is a decent CPU hit which even if the Zune plays those files it seems there will be a trade off with battery life/storage space assuming that increased CPU applies across basically anything that plays AAC files.

SIDE NOTE: i just noticed with a quick search online... http://forums.rockbox.org/index.php?topic=14259.0 ; it appears to say the same thing and even you said it back then which is about 9 years ago. but i guess i never noticed it because when i did use AAC occasionally it was always around 100kbps which i imagine uses the AAC-LC stuff as i was either using Nero's encoder years ago or more semi-recently the Apple AAC encoder and only very recently tried the Winamp FhG encoder as i heard that does well at low bit rates, which it seems to, but i did not know that it has a decent CPU trade off to get good sound quality at those really low bit rates.

[saratoga]

but i did not realize that AAC was that CPU intensive at any bit rates. i am surprised that needs more CPU than Opus does being AAC is older. like with Opus i can tell it's using quite a bit of CPU especially when changing tracks or when fast forwarding you can see a decent delay before it resumes playback(or changes tracks) when you release the fast forward button etc but Opus is basically useable on my e200 series v1 unlike AAC-HE.

You can use AAC-LC, just not AAC-HE, which is a different and much more complex format.  Configure your encoder to output LC and you won't have problems. 

Opus is comparable to AAC-LC in performance, we just haven't optimized it as well as AAC. 

[ThaCrip]

Opus is comparable to AAC-LC in performance, we just haven't optimized it as well as AAC.

So your saying Opus is basically similar to AAC-LC in terms of CPU usage in general, but it's just that in Rockbox it's not as optimized with Opus as AAC-LC(basically the more standard form of AAC) is(?) ; hence, why i have the issues that i do with Opus in Rockbox (even though it is useable especially if your not always changing tracks etc). like Opus is capable of running nice and smooth overall on Sansa e200 v1 series like AAC(AAC-LC) basically does. but assuming that's right... i just wonder if Opus performance in Rockbox will be eventually improved or is that not really something people are concerned with for the foreseeable future?

either way, i thank everyone for Rockbox as it's what made me get this Sansa in the first place nearly 10 years ago now as i think it was June 2008 when i got it.

You can use AAC-LC, just not AAC-HE, which is a different and much more complex format.  Configure your encoder to output LC and you won't have problems.

Ill have to play around with that in Foobar2000 (like FLAC to AAC-LC etc) and see if i can come up with something that's worth using.

thanks for your time

p.s. but i won't be surprised if, in the end, i stick with some MP3 variation especially considering space issues ain't nearly as much of a concern as they used to be(like 32GB MicroSD or even more are affordable(my current 16GB card is so-so if i put basically everything i have on it which is partially why i want to drop bit rates etc on at least a portion of what i got) and even LAME v2 offers safe sound(like quality sound output to where almost no one would complain about that level of sound quality) at a reasonable file size as i figure much higher than v2 (like say v1 or v0 and especially CBR 320kbps) sorta defeats the purpose of lossy audio which is mostly to find that sweet spot of quality sound at the lowest possible file size. i know opinions vary on this, but i definitely don't get why people use CBR 320kbps over v0 (i.e. 245kbps average) as 320kbps just seems like a space waster with very little to no benefit over LAME's highest VBR setting which, as you know, is v0 (i.e. 245kbps average) and if someone is going with MP3 @ CBR 320kbps it seems like they might has well just go for FLAC (if that's a option for them) if they are THAT concerned with sound quality.

EDIT: there don't seem to be a way to make the Winamp FhG encoder use AAC-LC with the usual VBR setting you normally use as i have to change to 'Constant Bit Rate' in Foobar2000 converter section to be able to choose AAC-LC. i am just wondering what's the proper option to encode AAC(AAC-LC) files with this Winamp FhG encoder at say 32kbps etc? ; because i tried the CBR and forcing AAC-LC @ 32kbps and the sound quality takes a solid hit vs using the VBR 32kbps (the one that taxes my e200 v1 series CPU on Rockbox) which says...

Codec Profile = AAC SBR+PS
Tool = fhgaac v03.02.16;VBR=1

NOTE: i am using newest Foobar2000 v1.3.16 and newest encoder pack from June 27th 2017 along with manually putting the Winamp FhG encoder files into the Foobar2000's encoder directory to get that (Winamp FhG) working.

i included a picture...

[ThaCrip]

Well since that FhG encoder don't seem to work in VBR mode @ 32kbps with AAC-LC in Foobar2000 i may consider going with Apple AAC @ q27 (64kbps) setting which uses AAC-LC with VBR mode automatically and still offers a small enough file size and cleans up the sound but without it taxing the Sansa e250's CPU like the FhG @ 32kbps does. because with FhG encoder in Foobar2000, AAC-LC does not take effect until the 96kbps setting where as with the Apple AAC encoder AAC-LC is still used @ q27 (64kbps) (and i think even lower to).

on a side note... i was playing around with some of Apple AAC's lower VBR settings which were 48kbps/56kbps/64kbps and compared them on the same song, without spending a bunch of time, and i could pick up the 48kbps(64kbps actual song rate)/56kbps(73kbps actual song rate) pretty quickly but with 64kbps(actual 83kbps song rate) i was not that confident i could hear any clear differences at that point when fairly quickly checking it through ABX. i never actually finished the whole 16 cycles in the ABX though but i would expect to comfortably pass the 48kbps/56kbps settings but with the 64kbps setting, at least on that one particular song i tested, i am not as confident i could detect it, if i can it's definitely not as easy/obvious. now... testing that same general scenario with LAME encoder i noticed that same point for me is... v8 (85kbps)(easy to detect) to V7 (100kbps)(not easy to detect). like with v8 i could detect pretty easily but with v7 i am not that confident anymore. the actual kbps for that particular song with LAME on v8 was 94kbps and v7 was 109kbps.

so with that info above... i have to at least somewhat correct what i said in my initial post in here which was 'LAME v4 being my point of transparency' because i just assumed i could do v5 (130kbps average) because i tried that on a different song on Aug 15th 2013 (using the same setup i am using now(i.e. PC speakers(Klipsch Pro-Media)) and passed the full ABX test (12 passes and got 11/12 (0.3%)). so maybe it's either just the song making it harder for me to detect now or is it possible my hearing is worse because i am slightly older now (37 at the moment (nearly 38) and back then i would have been 33, nearly 34.). but what i should do is test that specific song that i tested back in Aug 2013 as this way it can remove the potential of it being the song that's making it harder for me to detect differences (like that other song i just happened to test back in Aug 2013 might be easier to notice sound flaws vs the one i tested moments ago) and if i failed to detect it now on that same song @ v5(130kbps) then maybe my hearing is a touch worse(?). but i just thought i would mention this.

but with all of that said... it seems, at least based on the single song i tested, that Apple AAC @ q27(64kbps average) is similar to LAME @ v7(100kbps average). the actual bit rates on Apple AAC q27 and LAME v7, like mentioned above, is 83kbps(Apple AAC) and 109kbps(MP3). so at least based on those settings it appears Apple AAC is better than MP3 as it takes less bit rate to achieve roughly the same quality. but i think this is probably expected given what i can tell from the general word which seems to say that at higher bit rates all encoders are pretty much the same but at the lower bit rates AAC etc tend to be superior to MP3. superior as in achieves similar sound quality with less bit rate. but i am curious as to whether someone else around here feels similar to my claim here(i.e. Apple AAC q27 vs LAME v7 being roughly equivalent)?

but back to the general topic... what i might do is settle for Apple AAC @ q27(64kbps) as that, based on what i briefly tested above, seems to be decent enough sound quality(like nothing obviously negative for me(if more obvious sound issue do turn up in other songs i would imagine it will still be minimal)) while still maintaining a pretty minimal file size and while not as small as those 32kbps files, they are still much smaller than my general LAME v2 (190kbps average) i have been typically using on my general music collection (converted from FLAC source).

thanks for everyone's time as i should have a general idea of how ill handle things now (if anything turns up soon ill probably make another post here)

p.s. i just updated the Apple AAC encoder though with the iTunes v12.7 file as i extracted the AppleApplicationSupport.msi (using 7-zip) and installed only that which makes it so Foobar2000 can use Apple AAC encoding. but i can't imagine anything changed from a sound quality perspective being the one i was using was from Jan 2017 and now is Sep 2017. is AAC even being developed from a sound quality perspective anymore?