On Sun, 14 Dec 2014 01:14:16 -0800 Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> > -------------------------- > > Also, I have a question. > > > > Currently flac complains about 24-bit .wav files if they have > > old WAVEFORMATEX header and not 'proper' WAVEFORMATEXTENSIBLE > > header. However it writes such files itself. > > > > Is it better to fix this so it decodes 24-bit .flac files to .wav > > files with WAVEFORMATEXTENSIBLE header? Or is it better to leave > > things as is (for better compatibility with old programs)? > > That's a good question. I have no idea how to answer that. > > Maye what's needed is (another) command line flag.As someone who get this warning quite a lot when encoding (because the .wav files come from a closed hardware recorder which isn't going to get a firmware update), I don't mind too much which header gets written (because the wav file will be read with libsndfile), but I would mind if it meant that --verify when encoding didn't work for these files (I have no idea at what point the verification is done, but changing this does mean that the decoded file header will be different to the original input file, which might be the reason it's the way it is). Richard
Richard Ash wrote:> As someone who get this warning quite a lot when encoding (because the > .wav files come from a closed hardware recorder which isn't going to > get a firmware update), I don't mind too much which header gets > written (because the wav file will be read with libsndfile), but I would > mind if it meant that --verify when encoding didn't work for these > files (I have no idea at what point the verification is done, but > changing this does mean that the decoded file header will be different > to the original input file, which might be the reason it's the way it > is).Currently the header of a decoded WAV file can be different to the original WAV file because FLAC doesn't preserve 'fmt ' chunk. For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE header with channel mask == 3. Encode it to .flac then decode back to .wav. FLAC creates a 24-bit stereo .wav file with WAVEFORMATEX header.
On Sun, 14 Dec 2014 21:02:12 +0300 lvqcl <lvqcl.mail at gmail.com> wrote:> Richard Ash wrote: > > > As someone who get this warning quite a lot when encoding (because > > the .wav files come from a closed hardware recorder which isn't > > going to get a firmware update), I don't mind too much which header > > gets written (because the wav file will be read with libsndfile), > > but I would mind if it meant that --verify when encoding didn't > > work for these files (I have no idea at what point the verification > > is done, but changing this does mean that the decoded file header > > will be different to the original input file, which might be the > > reason it's the way it is). > > Currently the header of a decoded WAV file can be different to the > original WAV file because FLAC doesn't preserve 'fmt ' chunk. > > For example: create a 24-bit stereo .wav file with > WAVEFORMATEXTENSIBLE header with channel mask == 3. Encode it > to .flac then decode back to .wav. FLAC creates a 24-bit stereo .wav > file with WAVEFORMATEX header.That makes sense, thanks! Richard
On Dec 14, 2014, at 10:02 AM, lvqcl <lvqcl.mail at gmail.com> wrote:> Currently the header of a decoded WAV file can be different to the > original WAV file because FLAC doesn't preserve 'fmt ' chunk. > > For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE > header with channel mask == 3. Encode it to .flac then decode back to .wav. > FLAC creates a 24-bit stereo .wav file with WAVEFORMATEX header.Did you try this when using the FLAC command-line option --keep-foreign-metadata? I did not write the code for that option, but I did write a proposal for a method that would have allowed the header to be preserved for either WAV or AIFF. I'm not sure what was implemented, though, and I have not tested whether abnormal WAV headers are preserved. If --keep-foreign-metadata is not used, then nothing is preserved from the original WAV except the audio. Brian Willoughby