similar to: WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not described

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

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

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,

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

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

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 call

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

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

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

Replying to myself once again, since I seem to have found the answer I was looking for. Sorry for the noise. It seems CRAM is indeed misusing FLAC, since stated in the Notes section of the FLAC format for the FRAME_HEADER is the fact that only block size values 0110 and 0111 can be used for variable block size data (i.e., the block size is specified as an 8 or 16 bit value at the end of the

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

There is some time now that I reported this issue on the bugtracker: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1325 And this guy, jbr, kindly created a patch that solved the problem. What is needed now for the patch to be included in the SVN? About his patch, there is a remap table that maps the channel order from SMPTE order to Vorbis order. What is this SMPTE order? Vorbis specification

This patch to opus-tools adds optional support to WavPack lossless format as input to opusenc. Like support to FLAC, it depends on an external library, libwavpack, and may be disabled on configure. Lucas Clemente Vella (1): Reading input from WavPack files. Makefile.am | 7 +- configure.ac | 37 ++++++++ src/audio-in.c | 71 ++++++++------- src/opusenc.c | 19 +++- src/opusenc.h

This may not directly be a vorbis topic, but it could have some VERY serious implications for open source development. I read this morning on the doom9 site about the "Security Systems Standard and Certification Act." I not a lawyer so I'm just going by doom9's interpretation. Here's an excerpt from doom9: "Should it pass kiss your rights as a consumer by bye. As a side

On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala > <ville.syrjala at linux.intel.com> wrote: >> From: Ville Syrjälä <ville.syrjala at linux.intel.com> >> >> Replace the ad-hoc iturbt_709 property with the new standard >> COLOR_ENCODING property. Compiles, but not tested.