Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: WavPack-FLAC and its reliability (Read 5483 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WavPack-FLAC and its reliability

A few years ago I ripped several CDs with CUERipper, the CUETools ripping tool (which uses EAC internally). Each disc was ripped into a single WavPack + CUE file. Now I'm thinking of converting everything to FLAC (same, single file + CUE) using CUETools. I know that lossless is lossless, but:
- Would there be any “modification” to the original information (even minimal) if I convert WavPack -> FLAC -> WavPack -> FLAC -> WavPack -> FLAC………. a thousand times?
- Is WavPack safe and mature enough to preserve information "as is" without the risk of "changing or losing some bits" along the way when converting to other formats?
- Is there a way to check if the FLAC output file has "exactly" the same information?

Re: WavPack-FLAC and its reliability

Reply #1 –
Quote from: Radagast on
- Would there be any “modification” to the original information (even minimal) if I convert WavPack -> FLAC -> WavPack -> FLAC -> WavPack -> FLAC………. a thousand times?
The audio will never change, unless there's a problem with the tools you're using for the conversion. (Not all audio converters handle lossless audio correctly, although most can do it if you fiddle with the settings.)

FLAC is not designed to decompress to the original WAV file the way WavPack does, so the WAV file headers might be different after converting from WavPack to FLAC for the first time. The original WAV file headers are usually not important, so this change shouldn't make a difference for you. Repeating the conversion any number of times afterwards will not make any further difference.

Quote from: Radagast on
- Is WavPack safe and mature enough to preserve information "as is" without the risk of "changing or losing some bits" along the way when converting to other formats?
Yes.

Quote from: Radagast on
- Is there a way to check if the FLAC output file has "exactly" the same information?
Yes. I've used foobar2000 (with this plugin in older versions), but I'm sure there are other ways to do it.

Re: WavPack-FLAC and its reliability

Reply #2 –
I've seen situations - though I don't anymore remember where - when embedded cuesheets worked better with WavPack. That's probably because FLAC has two ways to store them. Sure FLAC is much more widely supported generally, but a bunch of tools don't support embedded cue at all it seems, and among those that do ...

As for WAVE headers: that is not an issue for CD rips. CDDA isn't stored as WAVE files. Not as files at all, actually.

(Also, more recent FLAC can store it correctly using the --keep-foreign-metadata-if-present - but that is more of a retro-fit hack to the format, and has to be invoked both on encoding and decoding or you will lose the headers with no warning. So yeah, WavPack is better suited when you want to preserve non-audi chunks - but for CDDA, that is moot.)

As for reliability:
* Use the official tool. Or something that invokes the official tool. ffmpeg has had bugs. Like this: https://hydrogenaud.io/index.php/topic,125848.0.html
* Do anyway verify afterwards. Say, what if you leave it overnight and your computer temporarily "loses" the drive - or it is full.

Re: WavPack-FLAC and its reliability

Reply #3 –
Quote from: Radagast on
- Is there a way to check if the FLAC output file has "exactly" the same information?
Besides directly comparing the audio data (with Foobar), you can also compare the MD5 checksums of the audio data with the MD5 checksum copies that you put into a tag before the conversion. Such a comparison is of course much faster, since you don't need to decode the audio again.
This can be done with something like Mp3tag, see here: https://hydrogenaud.io/index.php/topic,120210.0.html (let me know if it's too confusing; I wrote that a while back and I made some changes...).

Just make sure that whatever converter you're using actually generates the MD5 checksums during the conversion process. For FLAC you should be fine, but for WavPack it's not guaranteed (Audacity doesn't do that, I think).

Re: WavPack-FLAC and its reliability

Reply #4 –
WavPack will by default not write MD5. One has to actively invoke it with the -m switch (or, a conversion tool that invokes it).
Luckily for novice wavpackers, is that you can rename the executable with whatever options you like, with those set once and for all, drag and drop will do the job without having to use the command-line.

Edit: Also, there is the option to verify. That has to be invoked with wavpack -v (or flac -V, with capital V).
Also by the way, TAK and OptimFROG have optional MD5s. Monkey's is a different animal, it computes the checksum on the encoded bit stream.

It was asked whether WavPack is stable and mature. My impression is that it is quite rock solid as software - after all it's been around since before y2k, although not with the same file format.
Also, it does checks that I don't think FLAC does: close the file and reopen it to see that it has indeed been committed to drive. (Windows has had its evil ways with drive caching and potentially losing data. You aren't completely guaranteed against it, say if you are careless enough to set up a RAM drive.)


A few minor remarks:
 * Since these files are CD rips on Windows, they are unlikely to go by way of AIFF (or CAF): WavPack uses source file's endianness when computing MD5. FLAC translates audio to signed little-endian.
 * OP asked for exactly the same information, but I take it that it is audio-only. As pointed out in Reply#2, non-audio WAVE chunks don't come from the CD. (I think? EAC doesn't write any tags nor info like CD-Text in there?)
 * And this is wrong; CUERipper is CUERipper even if it produces EAC-style logs:
Quote from: Radagast on
CUERipper, the CUETools ripping tool (which uses EAC internally).