flac dev - Jan 2013 - Tag flac as flac 1.2.1_git

I seem to recall that changes in the second number indicated a minor change
in the *format* of the file itself (for example, 1.1.x to 1.2.x introduced
a new rice coding option used for 24-bit files). Are there any format
changes that would justify that ? Otherwise, 1.2.2 would seem more
appropriate, not to minimize the work that you are doing...

Cheers,
Pyt.
http://www.mjuware.com

On Sat, Jan 12, 2013 at 6:39 AM, Erik de Castro Lopo - mle+la at mega-nerd.com
<flac-dev.pyt.682528eb7b.mle+la#mega-nerd.com at ob.0sg.net> wrote:
> I'm currently looking to name it 1.3.0rc1. 1.3.0 because its been so
> long since the last offical release and because of the change of
> maintainership.
>


--
Pierre-Yves Thoulon
+33 (0)6 33 39 75 76
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20130112/3845cd0c/attachment.htm

pyth.flac-dev.5.pyt at spamgourmet.com wrote:
> I seem to recall that changes in the second number indicated a minor change
> in the *format* of the file itself (for example, 1.1.x to 1.2.x introduced
> a new rice coding option used for 24-bit files).
I wasn't aware of that.
> Are there any format changes that would justify that ?
I consider the first release in 5 years to be a sufficiently major
thing to warrant the bump in versions number, but if people thing
1.2.2 or 1.2.10 or whatever is mor appropriate then I'll go with
that.

Cheers,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

The initial rule was, if I can recall correctly :

- Changes in the first digit (e.g. 1.x.x to 2.x.x) indicate a break in
backwards compatibility ; i.e. the formats are totally different.
- Changes in the second digit indicate backward-compatible changes in the
format (i.e. a 1.1.x-encoded file is only a particular case of a
1.2.x-encoded file)
- Changes in the third digit reflect any other, non-format related, change.
In particular, any 1.2.x decoder can decode any 1.2.y-encoded file.

I think it best to stick to that, but you're doing the work, so you pick up
what you think best or easiest. I believe however it is good to have rules
that precisely govern what number changes.

Cheers,
Pyt.




On Sat, Jan 12, 2013 at 8:37 AM, Erik de Castro Lopo - mle+la at mega-nerd.com
<flac-dev.pyt.682528eb7b.mle+la#mega-nerd.com at ob.0sg.net> wrote:
> pyth.flac-dev.5.pyt at spamgourmet.com wrote:
>
> > I seem to recall that changes in the second number indicated a minor
> change
> > in the *format* of the file itself (for example, 1.1.x to 1.2.x
> introduced
> > a new rice coding option used for 24-bit files).
>
> I wasn't aware of that.
>
> > Are there any format changes that would justify that ?
>
> I consider the first release in 5 years to be a sufficiently major
> thing to warrant the bump in versions number, but if people thing
> 1.2.2 or 1.2.10 or whatever is mor appropriate then I'll go with
> that.
>
> Cheers,
> Erik
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/flac-dev/attachments/20130112/9a6eb9f5/attachment.htm

On 12-01-13 08:23, pyth.flac-dev.5.pyt at spamgourmet.com
wrote:
> I seem to recall that changes in the second number indicated a minor 
> change in the *format* of the file itself (for example, 1.1.x to 1.2.x 
> introduced a new rice coding option used for 24-bit files).
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)

On Jan 12, 2013, at 05:30, Martijn van Beurden wrote:
> On 12-01-13 08:23, pyth.flac-dev.5.pyt at spamgourmet.com wrote:
>> I seem to recall that changes in the second number indicated a minor
>> change in the *format* of the file itself (for example, 1.1.x to  
>> 1.2.x
>> introduced a new rice coding option used for 24-bit files).
>
> 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)

I strongly recommend against changing the format just to allow  
alternate labels for the same number of channels. The goal of channel  
mapping would be better served by defining meta data that would be  
legal for any 1.x file. Sorry I didn't say anything sooner regarding  
the proposed changes.


There are very good reasons not to revise the format version.

First of all, channel mapping happens entirely external to FLAC. No  
matter how precisely the channels are labeled, it is still possible  
for playback to happen incorrectly if the audio system is not also  
configured. For that matter, someone could play a 7.1 FLAC on a  
stereo system, and it would certainly not be mapped correctly in that  
case, no matter what version of FLAC file.

Second of all, the proposed changes are just being more specific  
about the 4, 5, and 6-channel variants, while adding definitions for  
7, and 8-channel variants. Nothing about the decoding process is  
affected by these human descriptions. Only the playback engine  
external to flac would be affected, and those details can be assumed.  
The order of 4, 5, and 6-channel FLAC files does not change - Ralph  
merely suggested being specific in labeling the front channels  
instead of just saying "left" and "right." Adding
specifications for
7, and 8-channel formats does not prevent a playback system from  
correctly decoding a 1.2.1 or earlier file and getting the channels  
right, provided that meta data is defined to facilitate this or even  
if the operator configures their system with care.


Bottom line: Channel labels are no reason to alter the version number  
of FLAC, and certainly not a reason to break backward and forward  
compatibility with all of the hardware devices that have already  
shipped with 1.2.x decoders. That said, we should put our heads  
together to come up with a new METADATA_BLOCK that could describe  
existing channel layouts as well as any variations that might be seen  
in the field.

I would suggest that everyone keep in mind the vast installed base of  
hardware FLAC recorders and players, and not senselessly make them  
obsolete without extremely compelling reasons.

Brian Willoughby
Sound Consulting

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/