Quality APE Encoder and Decoder Options

[Excelsius XS]

I have been using Monkey's audio for almost a year. I am obsessed with sound quality and use the highest settings in EAC with AccurateRip to rip all my CDs. Recently, I was furious to find out that the f****** Monkey's Audio does not provide any error correction/detection. This means that all my hard work could have been going down the drain. Could anyone please tell me what APE encoder/decoder can I use instead of that piece of shit Monkey's Audio? I read about WavPak, but am not sure how it works. I assume it encodes APE, but I have been unable to install Seek's frontend. Please recommend me something ASAP.

[shadowking]

There is no 'quality' settings in lossless and error correction has nothing to do with this either. Any monkey encoder is as lossless as any wavpack or flac encoder.

[Synthetic Soul]

Anything that encodes/decodes APE will no doubt be using the Monkey's Audio SDK, although it sounds like foobar uses adapted code, so it is possible it is a better decoder than MAC.EXE

WavPack creates WV file - completely different format.

You should do some reading in the wiki. Follow the link through to the comparison page and make your decision.

It is always possible that you could stick with APE and use alternative/additional error recovery, like PAR2.

[spoon]

APE writes an MD5 of the source audio data, it is upto the program you are encoding to, to decode the audio file and check it was written without error.

[[JAZ]]

Excelsius... you're wrong in several things :

First, MAC does have some form of error detection, it was discussed recently here. It just seems that it is dependant on the decoder, and of course, detection doesn't mean correction.

Next, MAC is open source (since only around 2~3 years IIRC), but afaik, there are no other variants that encode to .APE, so it's the only software to create them (not counting the commandline and library interfaces).

Wavpack is a good lossless codec. It is not as fast as MAC but it offers several other features that make it good, as well as having an active development.

About frontends, i can't suggest any, since i don't use them.



@shadowking : that answer of yours was a bit precipitated, wasn't it?

[guruboolez]

As far as I know, there are currently no lossless format providing error correction. When an error occurs, decoders can't correct it. But some of them could skip the error; such skipping usually imply the loss of a small musical part.
The amount of loss is bigger with Monkey's Audio (compared to flac or wavpack) and it increases with the strength of the compression (you can loose several seconds with -c5000/insane profile). In some cases, the decoder can't even resync the stream; in other words you can loose the whole part of the file located after the error.

[JAZ]> you can't say that WavPack is not as fast than Monkey's. It doesn't mean anything if you don't explicit the encoding profiles. By defaut WavPack is clearly faster than Monkey's on both encoding and decoding side - but the ratio isn't as good then.

[Hanky]

Data integrity on hardware or file system level is not the responsibility of a lossless audio codec IMO.

[guruboolez]

Data integrity on hardware or file system level is not the responsibility of a lossless audio codec IMO.

File organization isn't the responsability of the encoder either, but all of them are providing tagging support. It's called a feature and features are playing an important part in the choice of lossless format

This post has been edited by guruboolez: Nov 12 2006, 11:49

[shadowking]

Data integrity on hardware or file system level is not the responsibility of a lossless audio codec IMO.

Ahh. That is what I am trying to say. Nothing will save you from crummy hardware. Shouldn't blame the codec as the data is no longer lossless. No codec or any software can correct catastrophic hardware failure - they can report faults, maybe try to correct it but software is only as good as the hardware.

[[JAZ]]

[JAZ]> you can't say that WavPack is not as fast than Monkey's. It doesn't mean anything if you don't explicit the encoding profiles. By defaut WavPack is clearly faster than Monkey's on both encoding and decoding side - but the ratio isn't as good then.

You're right. I was talking for a similar compression ratio.

[Sunhillow]

First of all I want to state that "Excelsius XS" should choose his words with more care.
Monkey's Audio sure is everything but crap! If you don't like what it does, write your own lossless compressor that can reconstruct files from your scratched and stained CDs.
What I really hate are people who cannot even write a "hello world" sample in any programming language but have the audacity to talk of excellent software as a piece of shit. Shame on you!

[Excelsius XS]

Wow, I did not know that higher compression equaled more errors, Guru. I have been using MAC's "High" compression, but from now on I will only use the "Fast" mode. So are you saying that flac has better error prevention than APE? If so, I can switch to flac because I have been using it on and off. The problem is that APE has a much better tagging system that works great. I tried the tagging system with flac about a year ago and it sucked.

For all you pro's out there, please give me some information about preserving my files. I have amassed a large classical library of about 8000 files and growing (about 100GB). I am going to keep this library forever and want to know what can I do to preserve the integrity of the files. As I said, I use EAC to rip to .wav and then use MAC to convert the .wav to .ape. The thought that I could copy a perfect file from EAC and then lose the integrity just because I encoded it by MAC is horrible. If there are no "lossless" programs that have complete error correction, then maybe we should stop using that damn word "lossless." In my vocabulary, it can either be completely lossless or lossy. How can you dare calling something lossless even if you are losing a fraction of the data from that given file? Amazing.
And what would you recommend about the hardware? I read that some people suggest making a back up on a dvd, but I don't agree. While the disks of hard drive are almost hermetically sealed in a metal case, a dvd is in the open and a single scratch on the label side will cause permanent data loss. Even if the hard drive dies, you can pay someone to take out your data. It might be expensive (up to $1000), but at least you know that you could get your data back, especially if the data is worth over 100K.

[TBeck]

the integrity just because I encoded it by MAC is horrible. If there are no "lossless" programs that have complete error correction, then maybe we should stop using that damn word "lossless." In my vocabulary, it can either be completely lossless or lossy. How can you dare calling something lossless even if you are losing a fraction of the data from that given file? Amazing.

Following your definition even copying of a text file from for instance a harddisk to an usb stick is lossy, because someone could break the latter into pieces...

[greynol]

The thought that I could copy a perfect file from EAC and then lose the integrity just because I encoded it by MAC is horrible.

Amongst so many others (), how on earth did you arrive at this conclusion?

This post has been edited by greynol: Nov 12 2006, 22:52

[Excelsius XS]

First of all I want to state that "Excelsius XS" should choose his words with more care.
Monkey's Audio sure is everything but crap! If you don't like what it does, write your own lossless compressor that can reconstruct files from your scratched and stained CDs.
What I really hate are people who cannot even write a "hello world" sample in any programming language but have the audacity to talk of excellent software as a piece of shit. Shame on you!

I don't have to choose my words with care and it is not up to you to say what people can and cannot say in this forum. Apparently you're the only one "offended" by something I said that is not even offensive. Maybe I can't write a program, but when a program is called "lossless" I expect no data loss. You probably wouldn't care anyway, but I have spent almost four years painstakingly building a large library and now I feel betrayed and some of my work is trashed because someone decided to call their program "lossless" without making all the specifications clear.

And by the way, if I thought the same way you did, then I would have to say that over 90% of the worlds population, including you, are idiots because they have no knowledge of basic physics, but I don't think that way because I know that everyone is different and has a right to their own opinion, whether right or wrong.

[Sunhillow]

"lossless" means that de decoded audio is bit-identical to the original wave file, not more and not less. If the carrier of encoded data gets some (some!!) corrupt sectors that have not been automatically moved to the hotspare area of the disk (if it was stored on a hard disk), maybe some formats will be able to correct more loss than APE. But my experience is: one corrupt sector does never come alone!
Keeping your archive forever means:
# read all data carriers every few years, check for errors, copy those with errors to new ones.
# move your archive from time to time to an up to date storage medium if you don't want to fumble around with obsolete hardware

"lossless" never ever meant the ability to correct errors introduced either by hardware failures nor by media failures. "Complete error correction" belongs to the realm of fairy tales, not to reality because it is simply impossible!

This post has been edited by Sunhillow: Nov 12 2006, 23:02

[Excelsius XS]

Even if complete error correction is impossible, at least it seems that flac is better than APE in terms of errors. I really like APE, but given that it has more potential for errors than flac I have no choice but to switch. Maybe we need new software that uses ape or flac encoders but also incorporates an elaborate error correction, much like EAC.

[ggf31416]

Even if complete error correction is impossible, at least it seems that flac is better than APE in terms of errors. I really like APE, but given that it has more potential for errors than flac I have no choice but to switch. Maybe we need new software that uses ape or flac encoders but also incorporates an elaborate error correction, much like EAC.

If your files are being corrupted then you have a serious problem in your hardware. Check the RAM and always test the files after compressing.

[greynol]

I really like APE, but given that it has more potential for errors than flac I have no choice but to switch.

Again, how is it that you arrived at this erroneous conclusion?

[Excelsius XS]

My hardware is excellent. I have a custom brand new computer. I am not saying that my files are getting corrupted, I'm say that I MIGTH be getting little errors every time I compress and decompress my ape files since MAC does not detect errors.
Regarding the errors in APE I read about it in wikipedia where is compares all the lossless software and basically says that MAC has no error detection. Guruboolez also confirmed that you get less errors with flac and wavpak just a few posts above.

[Sunhillow]

What EAC does is completely different to what occurs on corrupt data media.
Audio data is stored with a very weak error correction. in case of more serious damage the CD reader has to guess some samples!
The error correction implemented in filesystems can correct some errors - or it discards further reading with an error message. Normally the erroneous data won't even get to your lossless decoder of choice, unless you use something like "unstoppable copier" to read a CD. This will fill up unreadable sectors with zeros.
What you (not "we", at least not "I") need is some level of RAID system that distributes all data plus correction information over several disks so that 1 disk may get lost.



Again, error detection is done by the filesystem.

This post has been edited by Sunhillow: Nov 12 2006, 23:24

[greynol]

Guruboolez also confirmed that you get less errors with flac and wavpak just a few posts above.

No, he didn't.

I hate to break it to you, but you're terribly mistaken about most everything you've said so far.

What guruboolez is trying to tell you is that *IF* your ape files happen to get corrupted, you'll not be able to get as much data back from them as you would *IF* your flac files happen to encounter the same corruption.

This does not mean that Monkey's Audio introduces errors while encoding.

Error correction in EAC and error correction as it relates to data are two totally different things. It is pointless to even compare them. BTW, despite what is shown in the EAC GUI, EAC performs no error correction.

Regarding the errors in APE I read about it in wikipedia where is compares all the lossless software and basically says that MAC has no error detection.

I see no such mention about lack of error detection in wikipedia. It does talk about error robustness which is not the same thing (and what it says isn't exactly correct, BTW); otherwise please provide a link to support your claim.

I also suggest you acquaint yourself with TOS #2. You've violated this twice already.

This post has been edited by greynol: Nov 12 2006, 23:45

[Hanky]

.... I'm say that I MIGTH be getting little errors every time I compress and decompress my ape files since MAC does not detect errors....

From Monkey's Audio FAQ:

Could you explain the error detection features in MAC?
The first thing MAC does when it compresses a frame (a small chunk of a file) is figure a 32-bit CRC for it. Then, it encodes that value at the front of the frame. When it decompresses a frame, it figures a CRC on the decompressed data and compares it to the original CRC.
This way, it compares the original data with the decompressed data. This is to say, if something is wrong in prediction (or anti-prediction) the original will not match the decompressed one.
Right now, CRC's are only used on the audio frames. In a future release, MAC will also CRC the WAV header and footer bytes also. (normally around 44 bytes a file)
Regardless, if a frame passes the CRC test, there is only about a one in billions chance of it being corrupt. If a file passes a verify, it means that all of the audio data is fully intact (every frame passed).
The only problem could ever be if there were disk I/O errors during encoding, so that what MAC thought it was supposed to encode wasn't what was really on the HD. HD's have error detection and correction, so the chances of this are about null. Also, once you enter disk I/O errors into the realm of possibilities, you can never really be safe.

I agree that 32 bit CRC is not the best error detection money can buy, but the chance that only one frame is randomly changed and produces the same CRC32 is negligible to me.

This post has been edited by Hanky: Nov 12 2006, 23:34

[Gambit]

I don't have to choose my words with care and it is not up to you to say what people can and cannot say in this forum.

Yeah, that's up to the TOS:
http://www.hydrogenaudio.org/forums/index.php?showtopic=3974

So please go read it.

[Excelsius XS]

I read it. I haven't violated anything, including #2, which is a very subjective rule. If a member claims that my post does not conform to his/her aesthetic standards, I can claim the same thing about that member. If you don't mind, I'd like to get back to the discussion...

greynol, what you say about APE makes it seem better, but it's still a problem that you can't get as much out of a corrupted APE than from FLAC. The word "Corruption" seems to be an ambiguous. It seems that if you define it scrupulously enough, it would mean that files in a computer get "corrupted" all the time and APE file, or any file for that matter, will eventually become completely useless because every little "unnoticeable" problem will add up and as time goes to infinity the corruption function will approach infinity as well. Is there anyone in here who knows what "corruption" really means? Is there a mathematical function to describe it? Considering that computers are based on 0's and 1's (linear algebra) I would think that there COULD be a corruption formula. That's intriguing and could elucidate a lot of aspects of this ambiguous discussion.

This post has been edited by Excelsius XS: Nov 13 2006, 00:17