I've read the comparisions between the two and know that APE compressesion is better than FLAC and started to use APE. then i came across something that said FLAC has a higher tollerence for errors.

Can someone explain this for me? Im quite confused upon this.

Tak a look at this post.

There have been issues with overclocked PC's , certain hardware configurations that make APE playback corrupt. Never seen it myself and I believe that the most problems are hardware or corrupt tagging.

This error tolerance anxiety may be linked to a subconcious fear of MA stalled developement / licence issue etc.. I may be wrong though.

Hmmm yeah it seems as tho FLAC does have a higher tollerence.

The encode/decode time ppl mention really perks my interest too becuz my cpu (3.2Ghz p4) seems to do ape(normal)/flac(8) about the same time. Maybe flac is a lil longer ... but on decoding my cpu doesnt even hiccup.

cpu usage is always @ 1% ...

I might just rencode my apes to flac afterall

Thanks

I could give you an example. Download and listen the two following files (< 450 Kb):

http://foobar2000.net/divers/temp/S25_KEYBOARD_Piano_C.ape
http://foobar2000.net/divers/temp/S25_KEYBOARD_Piano_C.flac

For both, I've changed two bytes in the middle of the file (with an hexadecimal editor). Now try to play them with your favorite player

Thanks!

okay switch in progress.

a hicup is preferable over silence and weird noises @ the end.

thanks-again

I think you should also consider WavPack, since it's one of the top contenders in the HA comparison.

I used a hex editor to do some tests for myself, both when deleting a random bit or changing one. foobar2000 0.8.3 passed with flying colors, and since I don't need anything other than foobar for playback and encoding/transcoding, I decided to stick with APE. Encoding is much faster than FLAC at -8, and file size is about as small as I can get without impacting CPU usage too much during decoding, which is pretty much as low as FLAC and Wavpack when encoded at -c3000 (high). The more files you have, the more size makes a difference. I think I'm saving about 15-20 gigabytes currently with around 425 CD's. The main things that FLAC has going for it is super low CPU usage, fast decoding (when to WAV), and is open source. When transcodig in foobar, there is a very negligable difference in speed between Monkey's Audio, Wavpack, and FLAC because the encoder is the bottleneck. If Monkey's Audio is not your thing, I would seriously suggest looking at Wavpack. Both encoding and decoding is super fast, CPU usage is very low, it's also open source, and file sizes are generally closer to APE than FLAC. Wavpack also passed my error tests in foobar.

Have you tried with Foobar 0.9 beta? It output errors and stopped decoding on both replaced bytes and deleted bytes.

Nah, it took me a long time to get foobar running just the way I like it back when I first started using it. Plus it does everything I need, so I haven't seen a pressing need to upgrade, though I may play with the beta at some point out of curiosity. Actually, when I have a lot of converting to do (like my entire collection to Vorbis for my Karma, which I redid recently) I set foobar to log everything to a text file and leave it running overnight (several nights actually). Having foobar stop because of one bad file would be annoying considering how long it takes to get such a large task done, especially since the only time I'm not working on my PC is overnight. When it's done, I just open the logfile and search that for errors.

Edit: Wait, did you possibly misunderstand me when I said foobar 0.8.3 passes with flying colors? What I meant by that was that foobar always reports errors properly on bad APE files.

Uhh yeah i used .83 & there were errors for both, tho the APE stopped playing completely and gave some weird noises, while FLAC just kinda had a hicup.

I'm not sure "what foobar does" should be how you judge these error tests. You should go by what the official executable encoder/decoder does. For example, some of the artificial error samples cause foobar to totally stop playing flac files at the point of the error. The executable, when you use the -F flag to force decoding through errors, creates only a tiny gap of no sound.

At least, that's what you should do if you're thinking about error resistance in terms of files stored in the HD. For streaming foobar (or whatever other player) is the important piece, but IMHO streaming errors are not worth worrying about. It's either a rare glitch that interrupts your music, or it's a sign that something's wrong or inadequate with your connection. Either way it has no permanent significance. Errors on your drive, on the other hand, are much more serious.

Also, for the people who are having fun doing experiments with artificial errors, someone should try zeroing out entire blocks of data, like 4kb at a time. This will of course create much larger gaps, but I'd like to see if it changes anything. In my experience this is the most common way to partially recover files from an almost dead HD -- entire clusters will be dead; recovery programs just leave them blank.

I did one flac file this way for my own entertainment and it was handled even better than the "small" errors. But I don't have a full toolset of other lossless encoders or the time to do a full comparison. Plus my hex editor only does paste in insert, not overwrite. It gets tiring holding down the zero key...

I disagree. Since I don't use the official decoder for anything, it would make no sense for me to test it. I think one should test whatever application they rely on for all their encoding/decoding purposes. I only mentioned foobar2000 because that is what I use (foo_ape 1.1 is the decoder, and I use the offical MAC.exe file for encoding). It's prefectly conceivable that one application may handle APE decoding errors better than FLAC, and another application the opposite. There are a lot of programs out there after all, and I doubt they are all created equal.

the reasoning behind all these "look at how much better foobar is" crap is to point out the differences in the codec.

one codec will absolutely die on any error, while another can skip or recover from an error. these situations will not change much with a chosen software decoder if it is a consequence of the format.


later

I'd be more worried about no errors being reported when a file contains them rather than whether or not a program/decoder might crap out. Like, for example, a link posted earlier in this thread pointing to tests showing that the official APE decoder can't be trusted because it doesn't report errors correctly. That thread is what prompted me to test APE decoding in foobar, which I found reports errors fine and generally only hiccups on playback. This was a good lesson for me because it showed that decoder implementation can vary from application to application. One should not trust any given app to decode any file type properly simply because one format is more popular than another, or has a better track record. Better safe than sorry as they say.

i only mention fb2k becuz its my audio player of choice. I was thinkin about switching to FLAC becuz of my Powerbook, and the possibility of a decoder for OSX. APE doesnt have any OSX support, then i read about the error handling stuff and it's only persuading me more towards flac.

of course it has: http://www.versiontracker.com/dyn/moreinfo/macosx/21952

next time google before posting rubbish.

Here 0.9b both reports error and stops decoding. The fact that foobar can manage to resync is indeed interesting, but trusting foobar alone - and specifically a version that will soon be replaced with one that might not resync - doesn't seem a wise choice for long-term storage.

0.9 beta 6 has options for not stopping.

Preferences, Playback, Error handling:
[ ] Stop playback on file open errors [ ] Stop playback on decoding errors

This means that APE library is capable of resyncing, and old 0.8.3 APE input allowed decoding to continue even after errors. This has changed for 0.9 (decoding must be aborted for error to be reported to user). With "stop playback on decoding errors" unchecked, it will advance to next track rather than resync. I suggest using different tools (commandline decoder?) for recovering broken files that decode past the point of corruption, otherwise we'd need "ignore decoding errors" option which is against my current design ideas.

Thanks for the clarification, Peter.

I find it amusing that the APE library can resync, yet the official APE tools - supposedly using this library - can't.

I assume that for other formats that can resync (mp3, flac, wavpack etc.) the treatment will be the same otherwise this would be unfair with the APE format.

There is no resync in the APE format, but there is a seek table located in the beginning. So after modifying some bits, it is possible to avoid the following bits in the same frame, and decode from the next frame.

But for deleting some bytes, it is hard to do the correct decoding.

didnt mean to post rubbish. I meant i wanted a player to play FLAC/APE easily w/out installation of a lot of appz and stuff. I had heard FLAC is a much better accepted platform wise thus i assumed FLAC would be a better alternative than APE. I dont wanna use Itunes/ALAC so i turned to these two.

Not a wise choice? Why? See, for me how well any given decoder performs only matters in so far as detecting that a particular file has errors and reporting it to me properly. As long as it does, what format I use shouldn't matter. I see an error as bad no matter the format, in which case once detected is fixed either by restoring a good copy from a backup, or by doing a re-rip of the CD the bad file came from. If being able to play back bad files with minimumal hiccups is what is most important, then yes, a persons codec decision should be based around that (in which case FLAC may indeed be the best choice, depends on the software doing the playback I guess). But lets face it, how many people base their choice on this? Most are either interested in good support (open source, cross platform), or performance (size, encode/decode speed, CPU usage). For me it was about performance, in which case APE at -c3000 was the one that hit the sweet spot, and since I use foobar for all my audio needs, error reporting is just fine and dandy too.

In my case, the lossless tracks are the backup. They are there in case I ever lose one of my CDs, either by having them stolen, or falling in the hands of my cursed nephews.



The problem with APE is not small hiccups, the songs might get undecodable past the error.

exactly ... well not nephews but damn dogs/roomates/friends/etc
Im afraid i wont have the luxury to rerip

Same here, my APE files are my backup. It's precisely because they are so important that I actually keep two separate copies of my music (each on a different hard drive). A bad file is a bad file after all, doesn't matter what the format is. No format can make up for lost or altered data.