i currently have most/all of my music collection (25-35 cds, i think) ripped with eac as flac, nice and organized. i use replaygain, etc, and need support for that.

i recently heard about wavpack, though, and have some questions:

1) For best compression, good decoding speed, cue file generation (is this possible when ripping separate tracks? if not, should i be ripping as images?), what is the best command line to eac in eac?

2) Do flac or wavpack have better compression if both are at highest compression level?

3) Do flac or wavpack have better encoding/decodig speed at higher compression level.

4) Is it worth reripping all of my cds as wavpack to get the cue files (which i'd like so i can burn backups of my cds using eac, which has a write offset in it to prevent generation loss) and whatever else is offered?

thx a ton,
Jack

At high compression level, WavPack (-h) compresses more than FLAC (-8).



At high compression level, WavPack (-h) compresses faster and decodes slower than FLAC (-8).

Here's a link to a nice comparison of speed vs. compression:
http://web.inter.nl.net/users/hvdh/lossless/All_old.htm



No need to rerip. If you want to migrate from FLAC to WavPack, you can just transcompress. I suppose Foobar2000 can automatize the process, while keeping all tags and CUE sheets.

WavPack has one advantage over FLAC in CUE shet handling, in that it allows you to store CD-TEXT data inside the CUE. FLAC strips that data from embedded CUE sheets.

what exactly is cd-text data? how can i embed cue files into flacs? can eac generate cue files when ripping separate tracks? can it generate cue files by looking at a cd while not ripping (so i don't have to rip my cds again to get the cue files)?

how would i automate the transcoding of my flac files to wavpack (if i decide to do so) with foobar?

CD-TEXT is actually in subcode channel data on CDs (more info here). it can hold all kinds of things including pictures but inside cue files, what is actually stored is usually just an abbreviated form, like the performer and track title, per track. so basically what it comes down to is storing the whole cuesheet in the tags. this can be done for both flac and wavpack the same way, usually with a program like foobar2000.

the extra thing about importing cuesheets into FLAC is this: FLAC has a special metadata section reserved for cuesheet info (except CDTEXT) in a structured way so that it can be easily used to automatically generate seekpoints, cue up tracks, regenerate the CD's table of contents, calculate CD hashes, etc. this metadata can be created by most programs that encode to flac, e.g. the command line encoder flac.exe with the --cuesheet option.

Josh

TITLE and PERFORMER statements within a cuesheet can be used to record artist, album, and title information. REM statements can provide supplimentary meta data, like genre and date.

FLAC has its own CUESHEET block, but that is the one that removes the CD Text data. You can also use a Vorbis comment, which is just like any other tag and will store the cuesheet as is. foobar can read this tag as well as the FLAC CUESHEET block.

No. See below.

Yes. "Action" > "Create CUE Sheet" > "Current Gap Settings...".

foobar copies tags across for you, so it's just a case of dragging all the FLAC files in foobar and then using Diskwriter/Converter to convert.


It appears that you currently have your files as separate tracks. Many people archive in this way (I, on the other hand, am an image with cuesheet man). If you are happiest with track files then I wouldn't worry about cuesheets and images and just stick as you are.

I would also consider leaving your files as is, and just looking at using WavPack for future rips, if you decide that WavPack is more preferable to FLAC.

NB: the main benefit of images over tracks is that, IMHO, it is easier to maintain gaps between tracks. If you want to be able to recreate the CD bit-perfect (or as close as hardware will allow) then images are easy, but with tracks you need to pay attention to what you are doing with gaps. Images are more of an effort to rip to, and play as, tracks, but foobar covers all that easily, and ACDIR is also an excellent command line app for transcoding from image/cue to tracks.

i recently heard about wavpack, though, and have some questions:

1) For best compression, good decoding speed, cue file generation (is this possible when ripping separate tracks? if not, should i be ripping as images?), what is the best command line to eac in eac?

cue file: No problem with separate tracks. Follow the way at http://www.High-Quality.ch.vu
I prefer personally separate tracks and have a cue sheet created by eac.
For best decoding speed (same speed as flac decoding) with better compression I recommend wavpack -x -m (+ the tag commands, see http://www.High-Quality.ch.vu)
(-x instead of the -h mode, which slows down the decoding to half speed).



2) Do flac or wavpack have better compression if both are at highest compression level?

Wavpack -x or -h have clearly better compression than flac at flac -8.

best compression of flac: flac -8
even better compression by wavpack: wavpack -x -m
nearly best compression of wavpack: wavpack -h -m (but half decoding speed)
best compression of wavpack: wavpack -h -x -m (but half decoding speed & painful slow encoding)
Compared to best compression of flac -8, you win the most with wavpack -x -m or -h -m.

3) Do flac or wavpack have better encoding/decodig speed at higher compression level.

Encoding speed:
(from Quickest going down to painful slow )
flac -5
flac -8
wavpack -h
wavpack -x
wavpack -h -x very slow

Though besides the -hx setting all other settings are well usable, even with eg. old P3 computers at 600-800 MHz.

Decoding speed:
(from Quickest going down to slower)
flac -5, -8; wavpack -x have the fastest decoding.
wavpack -h & -hx have 50% of the decoding speed above.


4) Is it worth reripping all of my cds as wavpack to get the cue files (which i'd like so i can burn backups of my cds using eac, which has a write offset in it to prevent generation loss) and whatever else is offered?

No, do not rerip.
well, it depends, if you want the cue sheet, as you had forgotten to create them ?
well again, if you ripped previously with eac according http://www.High-Quality.ch.vu taking care of the correct appending of the gaps, then you don't even need any cue sheet for burning, as you could eg. use nero, drop the tracks to nero window, and set the gaps from 2 seconds to 0 seconds, besides the pregap of the 1st track, it is red-book standard, to have there the 2 seconds gap.
There are some exceptions, where this very simple nero burning method is not so perfect, as it could cut away some samples at the beginning, though you have the 2 seconds gap mostly without content, so no harm.
imo, because of those few samples, and cue sheet, I would not rerip.
In the future, from now on, I would rip with eac following http://www.High-Quality.ch.vu with cue sheets to single tracks.
As written above, it will even not make much sense to transcode from flac to wavpack the older flac albums. The space win will not be too big. (Everything is relative, of course.)

not always, on this cd flac -6 beats wavpack -h by 5-10 meg atleast (i kept the flac version in the end and its final size was 78.8MB) i will admit that on most other albums wavpack does seem to outperform flac but not by a great ammount it also seems rather slow to replay gain in foobar compared to flac.

this is my final thoughts, if size is important go for ape (i really hated saying that) if you want a great number of features and a developer who listens to his users go for wavpack. flac is also very good (i have a lot of flac files i wont be converting to wavpack) but it does not have some features and the development seems slow.

In my personal experience wavpack -h compresses a little better than flac -8, but it's really not worth re-encoding a whole collection. For new rips however, it's a good choice, especially since it encodes substancially faster than flac -8.

Where wavpack really shines though, is on high-res content (ripped from DVD-Audio discs for instance), especially when brick-wall filters have been applied (which seems to be the case more often than not). Not only does wavpack compress much better with such content (often 20-50% more), the gains are also much more important (i.e. more interesting) in an absolute sense, since the files are already much bigger in the first place than 16 bit / 44.1 kHz audio. 10% of space gained on 24 bit / 96 kHz audio (100-150 MiB FLAC files) is much more interesting than the same ratio gained on CD-DA rips (40-80 MiB files)...

I did this exchange from FLAC -8 to Wavpack -hx some time ago. Sure it took quite some time to reencode over 30 albums but I didn't do all it once. I don't remember how much was the diskspace saving in percentage, but it was noticeable. The decoding speed difference hasn't been noticeable when playing and seeking works like before. I bet everyone have different opinnion about the worth of the exchange process, but if you ask me, it sure gives a bit more free diskspace. The reencoding process can be well automated with foobar2000.

For reference, if people want an alternative:

I recently converted around 350 APE files to WV.

I used MAC.EXE (shntool version), WAVPACK.EXE and TAG.EXE, e.g.:


You could do something similar using:



Slightly more info here.

Hi there, I am a bit confused but that statement. Does it mean wavpack -x is faster than flac -5? If so, how much faster? Is there a study made where decoding speed is discernible? In high quality audio equipment, there is sometime a comment about tempo or good timing. Does various decoding speed have an effect on tempo?

that statement is from 2 years ago.

If you're interested in comparing speeds it may be worth taking a look at some of the comparisons listed in the wiki, and probably the one on the FLAC site.

Thanks SS. It seams that flac have the upper hand (where decoding speed is concerned). This is probably why most hardware manufacturers are supporting it. Whether the speed advantage is significant to be discernible is pretty much beyond me. It appears that all lossless codecs are faster than uncompressed wav. It would imply that playback timing is not dependent on decoding speed but a different timing clock down the processing line. Which would mean, the codec with a higher compression rate would have the upper hand if variance in encoding/decoding speed is not great.

If the most time-consuming part of the playing process is reading the data from a storage device then the codec with the highest compression will be the fastest. This would explain why wav could be slower than lossless.