Re: [flac-dev] Tag flac as flac 1.2.1_git
On 22-01-13 08:20, Brian Willoughby wrote: >> Not even bug fixes? > What bugs? I'm not aware of any bugs. A centralized list of bugs > would be great. Well, the changelog in the docs directory has been used previously by Josh to keep track of all changes. It seems the code in cvs had some bugs fixed and libFLAC got an new function (FLAC__format_blocksize_is_subset()) so that should be enough to warrant a new version number right? Anyway, the Sourceforge bugtracker is still active: http://sourceforge.net/p/flac/bugs/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Define 6.1 and 7.1 channel mappings
On Jan 17, 2013, at 21:41, Ralph Giles wrote: > On 13-01-17 7:26 PM, Brian Willoughby wrote: >> I vote for documenting the --channel-map option in the --help > > Do you ever use --channel-map yourself, or recommend it to clients? Professional surround mastering is delivered on very specific media, and FLAC is not an option (to my knowledge). I use FLAC for archival of original recordings, and I document the channel order along with the other details of the recording. I recommend the same practice to anyone. FLAC works best with mono and stereo. Only stereo can take advantage of compression options that share channels. More than two channels in a FLAC does not really offer any space savings beyond what you would get with multiple mono FLAC files. But if you do archive 8-channels recordings, you'd be well advised to document more than just the channel mapping. Actually, there's quite a large world of possibilities. There are recording devices, archival methods, media exchange standards for mastering, and only after all of those stages is there delivery to the consumer. I'm not aware of any surround material being delivered in FLAC yet, neither to mastering houses or consumers. It seems that surround is mostly limited to Dolby Digital, DTS, and is limited to DVD and BD (Blu-ray Disc). I have seen some new things popping up, but many of them look really ugly in one aspect or another. Are you aware of FLAC being used apart from recording devices (1 to 8 channels), archival (multiple mono and stereo), computer audio, or consumer stereo audio? It seems that there are two areas where surround FLAC could take off (mastering formats and consumer media). Brian ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Tag flac as flac 1.2.1_git
On Jan 21, 2013, at 22:57, Erik de Castro Lopo wrote: > IMO, any code change at all, even just whitespace is worthy of its > own version number. If the md5sum of the source code tarball is > different it warrants an updated version number. Why would you release a new version of FLAC if the binary did not change (on a given platform)? I realize that whitespace is an extreme example, but in that case you don't really need a new version. The source code is only consumed by the developers. The version control system should handle "versions" of the source code. For example, Subversion would assign a new repository version number every time someone checks in a source code change. That is enough. There's no need to revise the release version with every developer's key press. It seems to me that you have to change more than source whitespace before a public release is warranted. A public release of substantial changes (not whitespace) would require at least a 0.0.1 increment in version number. >> 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. > > Its use in the test suite means it can't be extracted from the > FLAC library sources without replicating its capabilities which > would just be silly. It would be silly to replicate the command line utility, but you don't have to replicate it to change its version number, or to allow the version to digress from the format library version. >> 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. > > Not even bug fixes? What bugs? I'm not aware of any bugs. A centralized list of bugs would be great. I'm sure there is one and I just haven't looked at it in a while. Is the old bug database still active? Is there a bug search template or report showing the serious bugs that need fixing? >> 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. > > Sorry, but I actually think you have this completely around the wrong > way. FLAC files can be created without the flac command line utility. > That suggests that FLAC files should be marked with the *library* > version that was used to create them. The last suggestion on my part was a nod to the folks who want to define the channel mappings in a way that can be detected by players when looking at a specific media file. The FLAC format (library) does not need to be modified for this, because FLAC merely holds independent channels without any care about their order or position or labeling. But the command line utility might transcode channel mappings from other formats like WAVE or AIFF. In that case, having the command- line utility version number might help define the channel mapping. Then again, it would be better to define metadata specifically for the purpose of channel mappings rather than encoding the command-line version number into the stream. I'll just take this particular suggestion off the table, because there are better ways to provide the features desired. To clarify, I was not suggesting that the FLAC format version should be replaced by the command-line utility version - that would certainly be a bad idea, as you point out. I should have specified that I meant adding a secondary version number somewhere in the stream (meta blocks) to indicate any assumption about data that isn't part of individual channels. Brian ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Tag flac as flac 1.2.1_git
Brian Willoughby wrote: > 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. My main interest in FLAC is the library. I actually don't use the flac front-end utility myself apart from its use in the test suite. > 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. The code should definitely *not* stay at 1.2.1. IMO, any code change at all, even just whitespace is worthy of its own version number. If the md5sum of the source code tarball is different it warrants an updated version number. > 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. Its use in the test suite means it can't be extracted from the FLAC library sources without replicating its capabilities which would just be silly. > 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. Not even bug fixes? > 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. Sorry, but I actually think you have this completely around the wrong way. FLAC files can be created without the flac command line utility. That suggests that FLAC files should be marked with the *library* version that was used to create them. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] [PATCH] fix leftover files blocking 'make distcheck'
Ralph Giles wrote: > This unbreaks 'make distcheck' for me. Jenkins shows this stopped > working with f1841caba3. Applied. Thanks. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
