Martijn van Beurden wrote:> Well, the only change in format that might be merged before the next > release that I know of is the definition of the mapping of 7- and > 8-channel audio. As these were previously unmapped, this would qualify > to be a minor format change, as previous decoders won't decode 1.3.x > files properly (as they don't map channels for 7 and 8 channel audio)Err, this thread got away from me when I wasn't looking. My understanding is that the recent changes for 7 and 8 channels was a documentation change only. Before this change the layout of 7 and 8 channel files was undefined. After the change 7 and 8 channel files were specified as: 7 channels: front left, front right, front center, LFE, back center, side left, side right 8 channels: front left, front right, front center, LFE, back left, back right, side left, side right There were no code changes to the FLAC library or tools. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
On 17-01-13 08:10, Erik de Castro Lopo wrote:> There were no code changes to the FLAC library or tools.My mistake, I assumed that because of this documentation change, the FLAC utility would be updated as well to handle this correctly.
On 13-01-16 11:10 PM, Erik de Castro Lopo wrote:> My understanding is that the recent changes for 7 and 8 channels was > a documentation change only.I think we should also change the flac front-end utility to construct and interpret the WAVE channel mask for 7 and 8 channel files. No one has written that patch yet. FWIW I generally agree with Erik that 1.3.x is justified by the long period without a point release. Adding a channel mapping for 7 and 8 channel files is a small spec addition, and doesn't have a serious effect on deployed implementations. -r
The flac front-end utility should have its own version number, on a separate schedule from the flac library. I can see that we'd be able to add features to the utility quite extensively without ever changing the file format or the library. I realize that the utility has historically shared the library version number, but I see a strong case to separate them from each other to free up development possibilities. Apart from fixing some issues with newer compilers, the library is the same code. It should probably remain 1.2.1 or advance to 1.2.2 if there are actually any significant code changes. If we can agree on separating the library and utility version numbers, then I think we'll have a much better chance of agreeing on version numbers. Not to mention the fact that embedded devices without a command line or any other kind of utility won't needlessly see version number changes when the format remains the same. On that note, I suppose this means we might want to mark FLAC files with the version of the utility that created them, since the format version number won't indicate that going forward - perhaps an application block would be appropriate. Brian Willoughby Sound Consulting On Jan 17, 2013, at 09:27, Ralph Giles wrote:> On 13-01-16 11:10 PM, Erik de Castro Lopo wrote: >> My understanding is that the recent changes for 7 and 8 channels was >> a documentation change only. > > I think we should also change the flac front-end utility to construct > and interpret the WAVE channel mask for 7 and 8 channel files. No one > has written that patch yet. > > FWIW I generally agree with Erik that 1.3.x is justified by the long > period without a point release. Adding a channel mapping for 7 and 8 > channel files is a small spec addition, and doesn't have a serious > effect on deployed implementations.