The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=99257e177eac96fa41a107b423080232f59ebe45 also requires some changes in write_iff_headers() function: currently flac don't write WAVEFORMATEXTENSIBLE header if decoder_session->channel_mask is equal to 0, 1 or 3. After the commit 99257e17 flac should do this for channel_mask equal to 0, 4 or 3. The patch fixes this. -------------------------- 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)? -------------- next part -------------- A non-text attachment was scrubbed... Name: channel_mask.patch Type: application/octet-stream Size: 645 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20141214/ef2c9b03/attachment.obj
lvqcl wrote:> The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=99257e177eac96fa41a107b423080232f59ebe45 > also requires some changes in write_iff_headers() function: > > currently flac don't write WAVEFORMATEXTENSIBLE header if > decoder_session->channel_mask is equal to 0, 1 or 3. > After the commit 99257e17 flac should do this for channel_mask > equal to 0, 4 or 3. > > The patch fixes this.Applied, thanks.> -------------------------- > 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. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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
On Dec 14, 2014, at 1:14 AM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote:> lvqcl 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.I've never quite understood why FLAC acts this way. I use AIFF more than WAVE, so I largely ignored it. My vague recollection is that there were historical problems with the specification for WAVE, such that different programs had different ideas about what was a valid WAVE file. Things like 24-bit, which were not used much, if at all, in the early days of WAVE, were not officially part of the spec. I always assumed, or even remembered discussions, that FLAC does what it does for maximum compatibility with existing programs. We probably need some serious research into other programs and their treatment of WAVE. What can be read, and what is written by other software (and firmware). Ideally, FLAC would accept as wide as possible of a range of 'fmt ' chunks, while writing the most compatible variation.> Maye what's needed is (another) command line flag.Depending upon whether we find "one" official standard, or multiple, a command line flag might be useful to select the less common standards for those who need them. Of course, it's certainly useful to have a command-line option to suppress the warning, but I thought there already was one. I mentioned earlier that --keep-foreign-metadata should preserve the 'fmt ' chunk along with the rest. But I think preserving the original is a different topic than what to write when creating a "new" WAVE file from FLAC audio. Keep in mind that it's possible to decode to WAVE after encoding from AIFF, or the reverse. So in many cases there is no original to preserve. I've even used FLAC as a dirty way to convert between AIFF and WAVE when I didn't have any other tools (since I almost always have or need a FLAC version of an audio file anyway). Brian