Which is the best lossless codec?, Discussion thread Options

[rjamorim]

Not that I think there's too much good to be said for the Shorten format, but in the naime of fairness, setting "hardware support" to "yes" for WavPack and "no" for Shorten in the table isn't (quite fair).

Go ahead and fix it then! I didn't even know Shorten was supported in Rockbox.

[kanak]

It'd be great if the table mentions whether the format supports Embedded Cue Sheet.

[rjamorim]

It'd be great if the table mentions whether the format supports Embedded Cue Sheet.

I don't think that feature is meaningful enough. How many players support embedded cue sheet in lossless codecs?

That feature is mentioned in the individual comparisons though.

[audiomonkeyboy]

I just started backing up my cd collection with FLAC. From what I gather, FLAC is the best format for compatiblity and long term storage. Im not worried to much about filesize, as long as its close to other formats. Anyone have a different opinion? I would be curious to know since I just started using FLAC.

Thanks.

[halb27]

... FLAC is the best format for compatiblity and long term storage... Anyone have a different opinion? ...

FLAC is certainly a good format, but if it's only about archiving you don't have to worry much about compatibility. When I did lossless archiving some time ago I used Monkey extra high (-c4000) cause compression ratio is a bit better while encoding speed is still good. There was a discussion about Monkey here a few weeks ago and the discussion went for a while that error recovery isn't good with monkey. While this is true if you care a lot about your archive (do a second backup for instance because you do want to avoid a broken archive) there is nothing to be afraid of.

That's why I personnally would still prefer Monkey, but this isn't an essential preference: compression ratio among all the well-used encoders like FLAC, wavPack or Monkey doesn't differ very much.

This post has been edited by halb27: Oct 29 2006, 19:59

[Fandango]

I wonder what's the point of good error robustness anyway... I mean if the lossless audio file was damaged, then it's not lossless anymore.

The only practical way to make archiving really error robust is to use external error recovery systems like PAR2 or similar.

[halb27]

I shouldn't have written about error recovery but about error robustness as Fandango did, cause errors aren't recovered with FLAC. The effect of an error is just more local using FLAC.

This post has been edited by halb27: Oct 29 2006, 17:35

[audiomonkeyboy]

I shouldn't have written about error recovery but about error robustness as Fandango did, cause errors aren't recovered with FLAC. The effect of an error is just more local using FLAC.

Are errors recovered by any lossless format?

When you say use PAR, are their any settings or # of files that you recommend to use?

[halb27]

My method of choice (for my meanwhile lossy archive) is to backup to a second HD, to backup moreover to DVD from time to time, (and with my lossy productive archive I have another copy on my DAP). I keep these archives fairly well synchronized (not exactly true for the DVD archive).

As for PAR Fandango may be able to give an answer.

[rjamorim]

I wonder what's the point of good error robustness anyway... I mean if the lossless audio file was damaged, then it's not lossless anymore.

The only practical way to make archiving really error robust is to use external error recovery systems like PAR2 or similar.

The point is that, if the codec is robust, you can at least recover most of the damaged file. That's the point of archiving: protecting your precious data so that you can recover as much as possible should a catastrophe happen.

[halb27]

... That's the point of archiving: protecting your precious data so that you can recover as much as possible should a catastrophe happen. ...

Right, but in the catastrophy case (broken backup medium or so) you must expect to get into more serious trouble than just one file corrupted at one place. So thinking about a robust backup strategy is the better way to go IMO.

This post has been edited by halb27: Oct 29 2006, 20:13

[rjamorim]

Right, but in the catastrophy case (broken backup medium or so)

Catastrophy could also be a CD scratch, specially when you use Monkey's... :B

[halb27]

[Catastrophy could also be a CD scratch, specially when you use Monkey's... :B

As always, everything depends on what you expect. If your only concern is a tiny DVD scratch you are right.
But if you are thinking about a scratch all over a DVD things are different similar to the case when the DVD isn't readable at all.

A broken medium doesn't make the archiver happy, no matter whether using Monkey or FLAC. Moreover even if only one file is affected (but I can only be sure with further testing) I don't like the idea of using the corrupted file even if the corruptness effect is kept local. If it's just one file I'd rather rerip in case I had no backup.

Anyway to me it's essential to use a robust backup strategy.

[rjamorim]

As always, everything depends on what you expect. If your only concern is a tiny DVD scratch you are right.
But if you are thinking about a scratch all over a DVD things are different similar to the case when the DVD isn't readable at all.

A broken medium doesn't make the archiver happy, no matter whether using Monkey or FLAC.

yada yada. I don't know about you, but I never managed to accidentaly break a CD or DVD in two. Scratching, OTOH, is pretty much trivial.

[halb27]

yada yada. I don't know about you, but I never managed to accidentaly break a CD or DVD in two. Scratching, OTOH, is pretty much trivial.

It's been more than once that I was not able to read an old data CD/DVD at all.
Because of that I don't totally rely on DVD backups. My primary backup media are my second HD in my PC as well as the HD on my DAP, and from time to time I do an additional backup to DVD-RWs.

But we shouldn't continue this forever. Sure it's an advantage that FLAC is more error robust. But whether or not this is considered to be of practical importance is up to everybody and his personal considerations what kind of errors he wants to protect against, what kind of corrupted files are acceptible to him, and how he thinks about a backup strategy.

This post has been edited by halb27: Oct 30 2006, 08:22

[Egor]

Many people here (incl. me) use lossless archives not only as a backup, but also for transcoding-for-a-portable purposes. In such case decoding speed should be considered as a more important factor for codec comparisons than compression ratio.

[greynol]

I use MAC -c3000 which, like flac, can decode through errors (though how important is this really when you legally own the rights to your music?).

I think the decoding speed at this setting is just fine and am more than happy to give a little for it's superior compression over flac.

And for those who feel that one should consider both compression and speed, MAC -c3000 encodes *much* faster than flac when it is set to encode at a compression ratio that is competitive. Unless you plan on decoding more than a couple of times and are using -c3000, speed considerations should also include encoding time.

When using -c2000, the compression ratios are usually still better than anything flac can deliver AND the decoding speed is more comprable.

[guruboolez]

I use MAC -c3000 which, like flac, can decode through errors (though how important is this really when you legally own the rights to your music?).

What does that mean? (emphasis is mine)

And for those who feel that one should consider both compression and speed, MAC -c3000 encodes *much* faster than flac when it is set to encode at a compression ratio that is competitive.

Wrong: flac can't even compete with monkey's -c3000 on encoding ratio (and even with -c1000, at least with flac <1.1.2). The comparison is therefore pointless. flac works asymetrically (encoding speed is disconnected from the decoding one and the extra computation can't therefore be very 'ratio-efficient') whereas monkey is symetrical (you can expect much better ratios with complex encoding but the decoding speed will necessary drop).

When using -c2000, the compression ratios are usually still better than anything flac can deliver AND the decoding speed is more comprable.

Certainly not. Decoding speed on my computer:
flac -8 = x60 [x42 with foobar2000 0.8]
MAC -c2000 = x16

then speek comparison:
flac -8 = x44
MAC -c2000 = x16

and hans heiden
flac -8 = ~x50
mac -c2000 = ~x18

=> MAC -c2000 is between three and four time slower than flac.

This post has been edited by guruboolez: Oct 30 2006, 20:17

[greynol]

I forget that in some places it is ok to have a lossles copy of a disc that you never purchased.

But I don't feel like getting into it with you today guruboolez. Forget I even said anything.

This post has been edited by greynol: Oct 30 2006, 20:26

[rjamorim]

But I don't feel like getting into it with you today guruboolez.

How magnanimous. I would probably say the same after such a through beating :B

[guruboolez]

I forget that in some places it is ok to have a lossles copy of a disc that you never purchased.

You mostly forgot the point of a backup: it's to get substitutes of the original discs in case you lost some of them. Being legal doesn't mean being indestructible and unstealable. Otherwise people wouldn't spent hundred and hundred dollars in DVD-R, HDD and in addition spend a good part of their free time to make perfect copies and build a robust archiving strategy.
The legal aspect doesn't change the problem - that's why I'm asking for a clarification of your comment: it sounds senseless to me.

This post has been edited by guruboolez: Oct 30 2006, 21:05

[greynol]

I thought you were above playing the troll, Roberto. I hope you still don't think that MAC can't decode through errors as your table suggests.

@guruboolez:
A good archiving strategy involves redundancy. If you don't have a copy to re-rip, then you better make sure you still have a backup.

PS: As much as I loath the concept, in the US, if your disc is lost, broken or stolen, I'm pretty sure you no longer have the right to a digital copy unless you purchased it separately.

This post has been edited by greynol: Oct 30 2006, 21:28

[rjamorim]

I thought you were above playing the troll, Roberto.

haha, look who's speaking!

I hope you still don't think that MAC can't decode through errors as your table suggests.

I did several tests, documented them and released the results. Where are your tests?

[greynol]

haha, look who's speaking!

The rubber/glue argument. How cute!

I did several tests, documented them and released the results. Where are your tests?

I suppose you didn't try a file compressed using the High setting using Winamp's Disc Writer?

I guess your test wasn't that thorough.

This post has been edited by greynol: Oct 30 2006, 21:37

[rjamorim]

I suppose you didn't try a file compressed using the High setting using Winamp's Disc Writer?

I used the default setting, on Winamp, foobar and mac.exe

While it indeed worked fine when I just swapped bits, it borked on every case when I deleted bits: winamp crashed, mac.exe exited with an error, and foobar spit an error at the console.


So, where are your tests?