similar to: A couple of questions about channel mapping

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

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

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

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

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,

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

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

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

Hi, I would like to clear something up about Sample Rate, If the Frame header can look to the metadata block streaminfo for sample rate what (if anything limits it to 655350Hz)? Can all frame headers not just point to streaminfo and it be specified in streaminfo as all 1s ie 2^20-1 = 1,048,575Hz? It would be really good to be able to use 1MHz and beyond for some of my/our work. Does anything

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

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

Hello all! (cc-ing the flac-dev list) I would like to give an update as to the recent CELLAR work on the FLAC specification. • Work has been done to make internal and external links more accurate and reliable. • 'Rice Coding' has been clarified as 'Exponential Golomb Coding.' • Clarifications have been made for binary representation. • Typos and other small changes have been

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

A user of CRAM (http://swami.sourceforge.net/cram.php) sent in a bug report related to decoding of CRAM files. This issue occurs with flac-1.1.2 but not previous versions (such as flac-1.1.1). Note that the same file is used for this test (hopefully ruling out any issue with the encoder). Details of the issue: When calling FLAC__stream_decoder_process_single() the error callback is triggered

Hi. I was wondering if there was any interest in extending the flac container format to support sample rates above the 655k current limit. Please note this is not for using ridiculously high sample rate sourced audio for some imaginary audible benefit. I've been involved in some experimentation with offline upsampling in software prior to delivery to an external DAC as a way to bypass the

Federico Miyara wrote: ... > The file format allows some unused fields for future use, such as the > padding block. It could include a flag to indicate a change in the > format adding one more streaminfo byte which would allow up to 256 > channels (actually, 256 + 8), or it could trigger a new byte when 11111111. > > There is also an invalid block identifier (127) which could be

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

sorry if I'm not reading this close enough, I'm ploughing through a bunch of emails here, but the source of this problem is what I consider a design defect in FLAC which uses frame numbers to save space, and confusing logic for determining whether the frame number or sample number is stored. if I had it to do again I would just have it store the sample number always. if you are going to

Don't overlook the FLAC in Ogg container solution. That's established as a standard for some time now, as far as I know, and would probably be better than a new, proprietary multi mono bundle. I haven't used it myself, but people have been talking about it for a while, and I believe that some "FLAC" users are actually working with FLAC in Ogg container files. Brian