Conversion from FLAC to WAV Exact?

[Zten]

I have all my tunes stored in FLAC. And I playback all tunes on my SB2 in FLAC format. Yesterday, I used dBPOWERAMP to convert a FLAC file back to WAV and then burned it to a CD. When I take that newly burned CD and query it in the FreedB database, it did correctly grab the CD title/artist/songs, but it said it was "an INEXACT MATCH". Why is that? Why is not an EXACT match since it was CD Audio restored from FLAC?

[snarlydwarf]

Because freedb doesn't look at the actual song to determine what something is. It looks, basically, at the disc format: how many blocks is each track, where the 'index' marks are, etc.

So the intertrack gap then matters (is there a 2 second gap between songs when playing the original CD on a CD player? Did your ripping process preserver that?)

You'd be more likely to get an exact match if you ripped the entire CD as single FLAC and used a cue sheet for indexing, but you'd lose that information still when going back to CD unless you have some software that can keep that cue sheet around and use it to build the table of contents of the CD. All the CDDA->WAV->FLAC->WAV->CDDA steps would make keeping that cuesheet a pain.

[Zten]

OK. So I guess I am just probing at the claim that restoring a WAV from FLAC will result in the EXACT re-creation of the original wave file. I did not rip the CD down as one complete file, instead, each song is its own file. I guess I buy the explanation about the gap between songs as a possible answer. I for sure don't know enough to refute it.

One more question about FLAC. The "quality" setting used in EAC. It is a number from 1 to 8. I think I always use 5, just becuase someone on the forum here recommended it (not the best reason, but I didn't have anything better to go on!). As I understand it, the difference is not really quality, becuase any number used results in a lossless copy of the wave file, but the higher the number, the more processing power it takes and the more compressed the FLAC file will be, right? So when restoring a WAV from a FLAC, doesn't that "quality figure of merit" need to be used? dBPowerAmp never propeted me for that number so how did it know what to use?

[pfarrell]

Zten wrote:
> OK. So I guess I am just probing at the claim that restoring a WAV from
> FLAC will result in the EXACT re-creation of the original wave file. I
> did not rip the CD down as one complete file, instead, each song is its
> own file. I guess I buy the explanation about the gap between songs as a
> possible answer. I for sure don't know enough to refute it.

Any lossless compression scheme must recreate the original file.
But in practice there is often a little bit of padding
generated, so that the file size may be different.

I've checked using a binary diff and the data values are identical.



> One more question about FLAC. The "quality" setting used in EAC. It is
> a number from 1 to 8. I think I always use 5, just becuase someone on
> the forum here recommended it (not the best reason, but I didn't have
> anything better to go on!). As I understand it, the difference is not
> really quality, becuase any number used results in a lossless copy of
> the wave file, but the higher the number, the more processing power it
> takes and the more compressed the FLAC file will be, right? So when
> restoring a WAV from a FLAC, doesn't that "quality figure of merit"
> need to be used? dBPowerAmp never propeted me for that number so how
> did it know what to use?

The FLAC "quality" is mislabeled by most utilities, typically using the
same word/keyword as quality in a lossy codec such as MP3 or Ogg.

For Flac, it really is an indicator of how hard you want to compressor
to try to compress the file. Higher values result in slightly better
compression at the cost of much longer compression times.

The decompression time is constant and small. So if you are not waiting
for the compression, set it high. Most people don't bother, because
the improvement is tiny and the compression time increase is non-trivial.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

[snarlydwarf]

OK. So I guess I am just probing at the claim that restoring a WAV from FLAC will result in the EXACT re-creation of the original wave file. I did not rip the CD down as one complete file, instead, each song is its own file. I guess I buy the explanation about the gap between songs as a possible answer. I for sure don't know enough to refute it.

See http://www.freedb.org/modules.php?name=Sections&sop=viewarticle&artid=6 for how a CD is scanned. Basically all that matters is the table of contents (which lists the number of tracks and the length of each).

That's typically what's in a cue file... the actual data of the track is ignored completely.

[Zten]

I for sure like the idea of the binary diff confirming the files are identical. Thanks! You guys are always on top of this stuff.

Kind Regards,
Zten

[Mark Lanctot]

You not only have gaps, but you have offset. Simply put, the CD pickup isn't quite where it thinks it is. It's usually only off by a few samples (1 sample = 1/ 44100th of a second) but it's enough to make a ripped WAV not bit-identical to the original CD track.

You can adjust for offset in EAC but most people don't do this because the results are inaudible - the track starts too early/late or ends too early/late, but only by milliseconds. Since these portions of the tracks are usually silent, you won't notice anything.

See http://users.pandora.be/satcp/eacoffsets00.htm#-

[Josh Coalson]

--- Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
> Zten wrote:
> > OK. So I guess I am just probing at the claim that restoring a WAV
> from
> > FLAC will result in the EXACT re-creation of the original wave
> file. I
> > did not rip the CD down as one complete file, instead, each song is
> its
> > own file. I guess I buy the explanation about the gap between songs
> as a
> > possible answer. I for sure don't know enough to refute it.
>
> Any lossless compression scheme must recreate the original file.
> But in practice there is often a little bit of padding
> generated, so that the file size may be different.

FLAC does not introduce any padding; it always stores and
reproduces exactly the samples it was fed as input.

the process of ripping a CD as individual tracks can cause an
"inexact" freedb match if not done properly due to the gaps between
tracks.

Josh

[pfarrell]

Josh Coalson wrote:
> --- Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
>>Any lossless compression scheme must recreate the original file.
>>But in practice there is often a little bit of padding
>>generated, so that the file size may be different.
>

> FLAC does not introduce any padding; it always stores and
> reproduces exactly the samples it was fed as input.

I've not seen this, I've seen tiny changes, always just
empty blocks that have zero impact. Since they made no difference,
I didn't keep searching to find out exactly what caused it.

Given that I use two different OS (Win 2000 and Linux)
and three different programs (CDex, EAC and grip)
there are lots of places for the diffences to show up.


> the process of ripping a CD as individual tracks can cause an
> "inexact" freedb match if not done properly due to the gaps between
> tracks.

The cddb/freedb matching algorithm is pretty simple, maybe
even simplistic. Years ago I knew exactly what it was, I implemented
it for low level code in C. But its just a rough hash, so
there is lots of reasons for mistakes.

We had three of the same album, CD, same UPC, with three different
hash values.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html