16/44 APE Files Won't play properly on Clip Zip

[Legolad]

Hi folks,

I've recently ripped a bunch of discs to APE using Monkey's Audio.

When I boot into the Sansa firmware, the player doesn't show these new APE files at all. The Sansa firmware does still list the MP3s and some older FLACs I ripped previously. The Sansa firmware can also play all of the these older MP3s and FLACs.

When I boot into Rockbox, the database finds and lists everything (the old MP3s and FLACs, as well as the new APE files. Rockbox plays the old MP3s and FLACs without issue. However, when I try to play the newly ripped APE files, Rockbox intermittently freezes up during playback - like a bad stutter.

The only weird thing I can find in the newer APE files is the note about the cover art being "too large to display".
Could that be the cause of this problem?

Here is a link to one of the newly ripped APE files:
SAMPLE FILE: David Bowie - 01 - Watch That Man.ape https://drive.google.com/file/d/0B42ljdSnhDApZ2stUkR4VkZhU2s/edit?usp=sharing

And here is the File Info from Monkey's Audio:
FILE INFO FROM MONKEY'S AUDIO
Monkey's Audio 3.99 (Insane)
Format: 44.1 khz, 16 bit, 2 ch
Length: 4:29 (11885244 blocks)
Tag: APE Tag v2.00 (10402 bytes)
    Title: Watch That Man
    Album: Aladdin Sane
    Album Artist: David Bowie
    Genre: Pop/Rock
    Year: 1973 04 13
    Composer: David Bowie
    Disc: 1/1
    Label: EMI Music Distribution
    UPC: 4988006775107
    Style: Hard Rock; Glam Rock; Contemporary Pop/Rock; Proto-Punk; Experimental Rock; Album Rock; Art Rock
    Cover Art (front): <too large to display>
    Artist: David Bowie
    Track: 01/10
    Rating: 5
    Source: CD (Lossless)
    Tool Name: dBpoweramp Release 14.4
    Encoder: Monkeys Audio v4.06 PP
    Encoder Settings: -c="5000"
    AccurateRipResult: AccurateRip: Accurate (confidence 33)   [105A10CD]
    AccurateRipDiscID: 010-0010600a-0081571d-7a09bd0a-1

[saratoga]

That's normal. Insane compression on ape requires something like a desktop PC or high end cell phone processor to decode in real time.  Take a look at these benchmarks for ape on your CPU: http://www.rockbox.org/wiki/CodecPerformanceComparison#AMS_AS3525v2_w_47_40MHz_PClK_40ARM926EJ_45S_41

[Legolad]

Thanks, Saratoga!

If you don't mind, I have a few questions about these playback test results.
I see that my Clip Zip has the same processor as the Clip+ and Fuze v2, so that's why you linked to this test result:

Code: [Select]

r27289 on 05 July 2010 by Jennifer.
[b]Sansa FuzeV2 Monkeys Audio[/b]
ape_c1000.ape	 579.38% realtime	 Decode time - 30.36s	 41.42MHz
ape_c2000.ape	 410.78% realtime	 Decode time - 42.82s	 58.42MHz
ape_c3000.ape	 273.94% realtime	 Decode time - 64.21s	 87.61MHz
ape_c4000.ape	 107.34% realtime	 Decode time - 163.86s	 223.58MHz
ape_c5000.ape	 25.62% realtime	         Decode time - 686.43s	 936.76MHz

Looking at these APE results, I think this means that my processor is capable of playing the first sample (c1000.ape) at 579% of real time with a decode time of 30.36 seconds. The last item - 41.42MHz - looks like it's the processing speed used to do the decode.

If I'm right about that, it makes sense to me that the last file (c5000.ape) was created using Insane Compression. The 25% of realtime would account for the halting playback. But what should I make of the 936.76MHz? Is that a theoretical number? Or is that the maximum MHz for my processor and it still isn't enough to decode in 100% realtime?

So this begs the question: What is the actual value behind each of the Monkey's Audio compression settings?
To find out, I converted my sample song to each of the five settings.

The file size ranges from 31.2 MB (Insane) to 32.0 MB (Fast) - not enough to worry about in my case.

Listening to the files reveals no substantive difference in the first three compression levels (Fast, Normal, and High). The playback sounds the same and the fast forward and reverse seem to work fine in all three levels.
The Extra High file sounds the same as well, but it does have occasional freezing (every 10-20 seconds or so) similar to the Insane file. The Insane file freezes every other second so I can't really assess the sound quality.

I think this means I need to re-encode all my APE files using one of the first 3 compression settings.

What do you think? Am I missing anything here?

Thanks,
Legolad

[saratoga]

If I'm right about that, it makes sense to me that the last file (c5000.ape) was created using Insane Compression. The 25% of realtime would account for the halting playback. But what should I make of the 936.76MHz? Is that a theoretical number? Or is that the maximum MHz for my processor and it still isn't enough to decode in 100% realtime?

Its saying you'd need to run your processor at ~ 1GHz to decode that file without stuttering.  Since it only runs at clocks less than 250 MHz, you are out of luck.

Listening to the files reveals no substantive difference in the first three compression levels (Fast, Normal, and High).

Wait what?  You realize APE is a lossless format right? 

What do you think? Am I missing anything here?

Yes, using APE is dumb on a portable.  Its going to kill your battery life for no reason.  Just use flac, its about the same size as APE on lower settings, but many times more power efficient.

[Legolad]

Thanks again.

Wait what?  You realize APE is a lossless format right?

By your reaction I'm guessing I don't really understand what all of this means. For the record, I am new to lossless encoding and don't fully understand it. So please forgive my ignorance.

I had assumed that having different "levels" of APE compression meant that the encoding would take longer. I also assumed that there would be some substantive difference in the resulting files (e.g. better sound, smaller file size, etc). I did not anticipate that there would be such a huge hit to performance in the realtime decoding of the file.

From your comments, should I infer that FLAC and APE will sound the same, no matter what level of compression I use?

EDIT: I just found this table which I think clears up some of my confusion:  http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison
After reviewing this table, I want to say that lossless compression is focused strictly on file size and the speed of decode/encode. Do you think that's a fair statement?

[saratoga]

By your reaction I'm guessing I don't really understand what all of this means. For the record, I am new to lossless encoding and don't fully understand it. So please forgive my ignorance.

http://en.wikipedia.org/wiki/Lossless_compression

From your comments, should I infer that FLAC and APE will sound the same, no matter what level of compression I use?

Yes, by definition, and this is the entire purpose of lossless.  However, if you are unaware of this, I would question if lossless is even the correct choice for you to use.  If you simply want high quality, many formats can provide that at a fraction of the file size.

[Legolad]

Thanks, Saratoga. I appreciate all your help.

I understood it in theory, but this being the first time I ever did the encoding myself, it's the first time I've ever actually thought through what those settings actually do. It seems obvious now that you point it out. :-) I just reverted to MP3 thinking when I encountered the different levels of compression.

...if you are unaware of this, I would question if lossless is even the correct choice for you to use.

I think FLAC will suit my purposes.

When I started ripping my collection, I wanted an "archival" copy of my CDs that I can look to as being a 1:1 replacement of those CDs. Lossless is definitely what I wanted.

As a secondary priority I wanted the "best" archival format that would be usable in a variety of players (e.g. PC, Clip Zip, Car head-end). APE is clearly not the right format for that, but FLAC works just fine.

And, with the cost of storage dropping so low, I've purposefully decided to ignore file size for this project. It's just not important to me (unless it messes with compatibility in different players).

So FLAC it is!

Thanks again for all your help.