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. _______________________________________________ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
