similar to: WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not described

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,

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

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."

Martin Leese wrote: > 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 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

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

lvqcl wrote: > Martin Leese wrote: >> Why place restrictions on which speaker a >> user can use? ... >> Finally to answer your question, for a >> single-channel file, FLAC should accept any >> one of the three masks 0x00000001 (FL), >> 0x00000002 (FR), 0x00000004 (FC), plus any >> one of the 15 other single-bit masks, plus zero. Please note that the

I apologize for the terribly long message, but here goes. ------------------------------------------------------------------------------------------------- First, regarding existing tools that I now about. libavcodec and users (e.g. HandBrake): - if there are 6 channels or less, the layout is set by the decoder as per the FLAC specification - if there are more than 6 channels, the layout is

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 < >

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

This is equivalent and just makes the code shorter. --- src/flac/decode.c | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/src/flac/decode.c b/src/flac/decode.c index fa82c04..98fc430 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -333,32 +333,26 @@ FLAC__bool DecoderSession_process(DecoderSession *d) return false; /* set channel

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

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

The FLAC format specification never defined the semantics of 7- and 8-channel files, which has caused some pain for some years now. Attached is a patch to define them. I don't know if this follows "follows SMPTE/ITU-R recommendations," but it follows common tool practice. I chose the set of surround speaker designations used by home theatre systems, which is the same set used by the

Erik de Castro Lopo <mle+xiph@mega-nerd.com> wrote: > Martin Leese wrote: > > So what is "OggPCM"? I started this thread > > because I was puzzled why someone was > > changing a draft instead of the document > > itself. > > The original OggPCM was started by a person who really didn't > lnow what they were doing and wouldn't listen to

I have been tidying up the VorbisComment page in the XiphWiki. The problem with it was that it was a mixture of proposals and discussion of those proposals. This made it difficult for implementers to see what to implement. The problem section is: http://wiki.xiph.org/index.php/VorbisComment#New_ENCODER_field_name_proposal This is a mess, and all I could do was add attributions to the

On 10/25/18, Rodger Combs wrote: > >> On Oct 25, 2018, at 12:47, Martin Leese <martin.leese at stanfordalumni.org> >> wrote: ... >> An alternative approach is to only define >> popular layouts. For more obscure layouts, >> such as 2.1 and Mid/Side, assume that the >> person doing the encoding knew what they >> put in, and so knows what will come

Brendan Bolles wrote: > Hey everyone, according to Wikipedia's 4-year-old information, there is no > standard for putting metadata into an Ogg file. True. > That metadata must be > included in the codec. More generally, in a stream in the Ogg file. Codecs are streams, but so are things like Ogg Skeleton. Information about Metadata has been collected together in the Xiph Wiki

On 7/23/13, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On 23 Jul 2013 15:17, "Martin Leese" <martin.leese at stanfordalumni.org> > wrote: ... >> Information about Metadata >> has been collected together in the Xiph Wiki >> at: >> https://wiki.xiph.org/Metadata > > That page is a bit outdated. It has CMML in it which we

"Kurosawa, Taku" wrote: > Hi Martijn, > > Sorry for the late reply again, > The application we are preparing this time is not exactly similar to > Replaygain. > > Replaygain as we understand is something which normalize the loudness at > content provider side, but our application takes different approach. It is > designed to normalize the loudness at player

Rodger Combs wrote: > I've run into some issues using Opus with source files in channel layouts > other than the default 8. For instance, 2.1 isn't supported, so I have to > either downconvert to 2.0 or upconvert to 5.1 (which usually involves adding > empty channels, which prevents the playback device from upconverting to the > native layout). > To address this,