Rockbox General > Rockbox General Discussion

Re: AAC-HE Playback bug

<< < (4/5) > >>

Bilgus:
It does boost with cpu boost 64 -> 131Mhz and I already tried making that boosted always problem still appears
the issue doesn't happen on my ClipZip so its either this fuze+ or the port its self

Bilgus:
Ok fixed http://gerrit.rockbox.org/r/#/c/1699/

Yes the Fuze+ plays m4a AAC-HE files

ThaCrip:
Nice to see you figured it out. kinda funny how a simple test ended in you discovering a bug ;)

but a couple of questions...

A)Would those AAC-HE files play fine if i had a e200 series v2? ; it appears the CPU on those is 250 Mhz vs i think two 80Mhz CPU's on my v1 according to the wikipedia page.

B)Does that 64kbps Opus file play fine on your Fuze+ etc without sluggish navigation of the Rockbox menus while the file is playing?

in regards to B... like i was saying they play fine on my e250 v1 but while the music file is playing and i start navigating through the Rockbox menu's, the menu's gets a bit sluggish. like not as quick to respond like it usually is when playing MP3/AAC-LC etc as it's usually nice and fast which is excepted. but given it seems your CPU is quite a bit more powerful than my e250 v1 i would not be surprised if you don't have this problem(?).

p.s. given what little i tested (on that AAC-HE song you tested)... if i were to use a bit rate that low i might as well use Opus on Rockbox simply because when ABXing, while i can definitely notice the FLAC vs the Opus/AAC-HE (both @ 32kbps setting even though with that song Opus comes out to 34kbps and the AAC-HE comes out to 37kbps), they seem similar enough to each other and i would imagine, given my experiences with both on my e200 series v1 player, that Opus likely uses noticeably less CPU (since the Opus is useable where as the AAC-HE is not), while maintaining similar level of sound quality, which i would imagine would have a decent effect on battery runtime. but this was mostly just a test as at the end of the day, at least for me, it's not really worth using 32kbps Opus over 64kbps as you still get small file sizes with 64kbps Opus and sound is noticeably cleaned up vs the 32kbps setting. like with Opus you can notice the increase in sound quality from 32kbps to 48kbps to 64kbps. basically ill say this in regards to myself... on Opus v1.2.1 once i hit 64kbps, ABXing becomes more difficult as even if i can ABX that song at 64kbps i would not be surprised if i could not ABX it if i bumped it up to 80kbps and seeing a couple of random users recent posts over on hydrogenaudio it seems some people are similar to me. i know they say that Opus @ 96kbps or 128kbps is pretty strong from the general word on hydrogenaudio from what i could tell. NOTE: these ABX test and my claims above were done on my PC with Klipsch Pro-Media speakers. who knows what would happen if i had some decent headphones but i don't see too much changing because even if i can detect 64kbps Opus from the FLAC files, it won't be easy, especially when your not switching back and fourth between the two (like Sample A and Sample B(where one is the lossless file and the other is the lossy file) in the ABX test it will be harder to notice straight up when listening in general since you can't instantly switch back to the FLAC file like you can in a ABX test) which i figure makes 64kbps a pretty good setting (for low file size and respectable sound quality) if your trying to maximize storage space on a Rockbox device with Opus format. even 32kbps Opus v1.2.1 sounds respectable (similar to what you heard with that 32kbps AAC-HE file) considering the very low bit rates.

Bilgus:
The opus file didn't even make it sweat and now with the AAC-HE fixed no issues on navigation there either but it does tax the cpu it takes easily 250MHZ to do that AAC-HE file on the fuze+ but it all depends on the cpu, Saratoga gave me a link yesterday that I knew about but had since forgotten that might answer your questions
https://www.rockbox.org/wiki/CodecPerformanceComparison

ThaCrip:
Assuming that's fairly accurate on modern builds of Rockbox, that should give me the general idea. just looking at MP3 vs AAC-LC decode times it seems there's roughly a 12-13Mhz difference with AAC-LC needing about 12-13Mhz more to decode.

is that 12-13Mhz or so difference have much effect on battery runtime?, or is it one of those things that mean, for example... say something needs 21Mhz to decode and gives you 20 hours of battery would that mean if something needs 42Mhz to decode that you would then have 10 hours of battery? ; or are things not linear like that? ; because if it was linear then that would mean ill get hours less of battery runtime currently since i recently switched to AAC-LC instead of MP3 (re-ripped my entire collection from FLAC to AAC-LC) i was using on my collection. i don't mind some drop off i just don't want anything significant. either way, even if there is a solid drop off in battery i guess it boils down to whether i want more efficient use of storage space vs battery runtimes on my e200.

also, has stuff changed much since those tests (on that website link) since those tests are more than 7 years ago?

also, i see they are using Nero's AAC-LC encoder which nowadays no one uses as it's outdated as the Apple AAC encoder is basically the standard for AAC-LC which is what i use (i.e. 'AppleApplicationSupport.msi' extracted out of the iTunes installer and then installed and then Foobar2000 can then encode Apple AAC files) for encoding my AAC-LC files from FLAC in Foobar2000 to Apple AAC @ q63 TVBR 128kbps (some use CVBR mode to(which seem to be similar sound quality but the CVBR files tend to be a little larger etc)). but i am not sure if that would matter on the Mhz needed to decode on said device with the Nero encoder vs the Apple encoder(?) or is it safe to say they are similar given the way AAC-LC works in general(?).

thanks for the info as i figured your device (Fuze+) would be totally okay on the Opus if it's fast enough to play those AAC-HE files, but i just wanted to confirm it with you.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version