search for: waveformatextensible_channel_mask

lvqcl wrote: > Martin Leese wrote: >> Note that the channel order may not be defined. > > IMHO it doesn't matter in this place of documentation (which describes > default channel assignments for FLAC). Your proposed wording was: 0000-0111 : (number of independent channels)-1. The channel order follows SMPTE/ITU-R recommendations. The assignments are as follows: The

On 7/16/15, Martin Leese <martin.leese at stanfordalumni.org> wrote: > Martijn van Beurden wrote: >> I would propose: 0000-0111 : (number of independent channels)-1. >> The channel order is defined through the >> WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If >> no WAVEFORMATEXTENSIBLE_CHANNEL_MASK is present, the channel >> order follows SMPTE/ITU-R recommendations, which are as follows: > > This looks like an excellent proposal. I tried to find the specific SMPTE/ITU-R recommendation on channel order....

An issue was raised at <http://forum.doom9.org/showthread.php?p=1728923#post1728923> - FLAC uses WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to describe non-standard layout, but it isn't mentioned anywhere in FLAC format. Channel assignment is described at <https://xiph.org/flac/format.html#frame_header>: "Where defined, the channel order follows SMPTE/ITU-R recommendations." The undefined value (0000?) is not...

Martijn van Beurden wrote: > Op 16-07-15 om 17:58 schreef lvqcl: >> But this text describes only those 4 bits in frame header. >> IMHO this sectoin should not describe WAVEFORMATEXTENSIBLE_CHANNEL_MASK, >> it should be described somewhere in vorbis comments section. > > I would propose: 0000-0111 : (number of independent channels)-1. > The channel order is defined through the > WAVEFORMATEXTENSIBLE_CHANNEL_MASK vorbis comment, if defined. If > no WAVEFORMATEXTENSIBLE_CHANNEL_...

Maybe I don't understand you correctly, but 0000 is mono, not undefined. It says: 0000-0111 : (number of independent channels)-1 I agree that the use of WAVEFORMATEXTENSIBLE_CHANNEL_MASK should be documented. I can probably take a look at it this week or so, if no one hasn't already? 2015-07-05 13:54 GMT+02:00 lvqcl <lvqcl.mail at gmail.com>: > An issue was raised at < > http://forum.doom9.org/showthread.php?p=1728923#post1728923> - > FLAC uses WAVEFORMAT...

...follows SMPTE/ITU-R recommendations. The assignments are as follows: > > The channel order might not follow SMPTE/ITU-R > recommendations, so this proposed wording > seems misleading to me. But this text describes only those 4 bits in frame header. IMHO this sectoin should not describe WAVEFORMATEXTENSIBLE_CHANNEL_MASK, it should be described somewhere in vorbis comments section. >>> So the WAVEFORMATEXTENSIBLE channel >>> mask is saved ONLY when the channel order >>> does not follow SMPTE/ITU-R recommendations. >> >> Not quite true. > > Then the changelog at: >...

Currently FLAC doesn't read the contents of WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag in a decoded FLAC file and doesn't write correct channel mask to a WAV file. (d->channel_mask == 0 inside DecoderSession_process() function in decode.c) The attached patch fixes this problem but I'm not sure that it doesn't have any side effects... Also, maybe it's better to...

lvqcl wrote: ... > From FLAC 1.2.1 documentation: > > 0000-0111 : (number of independent channels)-1. Where defined, the channel > order follows SMPTE/ITU-R recommendations. The assignments are as follows: > 1 channel: mono > 2 channels: left, right > 3 channels: left, right, center > 4 channels: left, right, back left, back right > 5 channels: left, right, center,

It seems that it's possible to make slightly less intrusive patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: mask_v3.patch Type: application/octet-stream Size: 711 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140426/11d64c6f/attachment.obj

...y repeat the number of channels (initially specified in the STREAMINFO block). The "Channel assignment" bits in FRAME_HEADER also contain the Channel assignment and, when these two uses of the same four bits are in conflict, a different channel assignment can be specified in the FLAC tag WAVEFORMATEXTENSIBLE_CHANNEL_MASK. (If the two uses of the "Channel assignment" bits in FRAME_HEADER do not conflict then the FLAC tag serves no purpose.) So, in your example above, the FLAC tag containing the channel mask 0x33 is redundant while 0x603 is not. The WAVEFORMATEXTENSIBLE_CHANNEL_MASK also specifies the cha...

Sorry for the delay; I have been waiting for SourceForge to come back on-line. lvqcl wrote: > 1) It seems that some programs (eac3to) write the value of > WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag with uppercase 'x' (e.g. 0X3) > (see <http://forum.doom9.org/showthread.php?p=1728852#post1728852>) > > Also, from MediaInfo changelog <https://mediaarea.net/MediaInfo/ChangeLog>: > Version 0.7.74, 2015-05-25 > x VorbisComment: WAVEFORMATEXTENSIBLE_CHANNEL_MAS...

...cess(DecoderSession *d) return false; /* set channel mapping */ - if(!d->channel_map_none) { - /* currently FLAC order matches SMPTE/WAVEFORMATEXTENSIBLE order, so no reordering is necessary; see encode.c */ - /* only the channel mask must be set if it was not already picked up from the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag */ + /* currently FLAC order matches SMPTE/WAVEFORMATEXTENSIBLE order, so no reordering is necessary; see encode.c */ + /* only the channel mask must be set if it was not already picked up from the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag */ + if(!d->channel_map_none && d->channel_ma...

...nt order; FLAC files must also be decoded with --channel-map=none to restore correct order." is misleading: FLAC never changes the order of channels. Decoding with this options also sets the channel mask of the resulting WAV file to 0. Without this option the mask is equal to the value of WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag. -------------- next part -------------- A non-text attachment was scrubbed... Name: 12_channel_order.patch Type: application/octet-stream Size: 3002 bytes Desc: not available Url : http://lists.xiph.org/pipermail/flac-dev/attachments/20140628/2720fee2/attachment.obj

...rder. Reasons: - "Where defined, the channel order follows SMPTE/ITU-R recommendations." -> all defined assignments are compatible with WAVEFORMATEXTENSIBLE (see above) - the official FLAC encoder uses a Vorbis comment to store the channel mask, as per WAVEFORMATEXTENSIBLE ("WAVEFORMATEXTENSIBLE_CHANNEL_MASK") - it is my understanding that the official FLAC encoder and decoder already use the "Microsoft order", though being unfamiliar with it, I have no idea what this really means ------------------------------------------------------------------------------------------------- One o...

Tim's proposal seems reasonable but it conflicts with the FLAC documentation that says the channel ordering follows SMPTE/ITU-R recommendations. I think we may be butting up against an area where the standards aren't clear. ITU-R BS.2159-4 (http://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BS.2159-4-2012-PDF-E.pdf) doesn't define a 7.1 layout but simply diagrams several possibilities on

I know I've read about it under the FAQ and other various forums a dozen times, FLAC is able to encode up to 8 channels. But has anyone actually tried to do this? I ran across this nifty 7.1 wav sample courtesy of Microsoft. http://www.microsoft.com/windows/windowsmedia/howto/articles/Multichannel.aspx#link6 For some reason the channel mask was incorrectly set to 0x3f, so I manually changed