Topic: Problem encoding to FLAC

[Keyd]

I have a 24 bit 44100 wav file that I put in protools, performed minor eq, cut into tracks, PowR dither to 16 bit and bounced out as wav files (tracks).

When I try to encode to FLAC, it makes a FLAC file MUCH smaller than the wav file and give me errors stating- WARNING: skipping unknown sub-chunk 'ovwf'
and WARNING: skipping unknown sub-chunk 'umid'.

I can get a checksum or ffp file from these FLAC files.

When decoding the FLAC files back to wav, the files go back to the MUCH larger size of the original wav file as a wav file.

I have had the same results on macflac or traders little helper on a PC.

Is something wrong with the files? Am I doing something wrong? Can I upload these FLAC files?

[Arni99]

http://flac.sourceforge.net/faq.html#tools__skipped_subchunk

"I compressed a WAVE file to FLAC and it said "warning: skipping unknown sub-chunk LIST". Why?

WAVE is a complicated standard; many kinds of data besides audio data can be put in it. Most likely what has happened is that the application that created the original WAVE file also added some extra information for it's own use, which FLAC does not store or recreate (see also). But the audio data in the two WAVE files will be identical. There are other tools to compare just the audio content of two WAVE files; ExactAudioCopy has such a feature.

For the more technically inclined, FLAC only stores what is in the 'fmt ' and 'data' sub-chunks of a WAVE file."

Of course the encoded FLAC file is smaller than the WAV file , but it uses LOSLESS compression, so no audio-information gets lost by this encoding process.

[Keyd]

Thanks Arni. I didn't see that on that page.

I guess they are ok.

I'm trippin. 

I thought they were similiar in size before. I guess not.

I will check the recorder and reader and watch closer on the initial process of importing the files to the computer.

[John Kary]

Thanks Arni. I didn't see that on that page.

Most audio-editing apps store metadata within the WAVE header that it uses internally.  Usually it is not a problem that FLAC does not store this data.  But, I do wonder why FLAC doesn't bother to store it in some way.  After-all, FLAC does support ReplayGain, which is also simply metadata.  Why not have a catch-all associative array that stores all of the sub-head info on encode?