search for: waveformatextensible

The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=99257e177eac96fa41a107b423080232f59ebe45 also requires some changes in write_iff_headers() function: currently flac don't write WAVEFORMATEXTENSIBLE header if decoder_session->channel_mask is equal to 0, 1 or 3. After the commit 99257e17 flac should do this for channel_mask equal to 0, 4 or 3. The patch fixes this. -------------------------- Also, I have a question. Currently flac complains about 24-bit .wav files if they have old WAVEF...

...el map, so the text should be (IMHO): > > 0000-0111 : (number of independent channels)-1. The channel order follows > SMPTE/ITU-R recommendations. The assignments are as follows: Note that the channel order may not be defined. An example of this is in the Microsoft documentation defining WAVEFORMATEXTENSIBLE. The final example is titled "Multiple mono streams (no speaker location)", and has a (valid) channel mask of zero (dwChannelMask = 0). Also note that in the changelog at: https://xiph.org/flac/changelog.html it states: Now properly supports ... WAVEFORMATEXTENSIBLE multichannel...

...-> 7 channels, 6.1 (front left, right, center, lfe, back center, side left, right) -> 8 channels, 7.1 (front left, right, center, lfe, back left, right, side left, right) - the FLAC decoder and encoder do not reorder channels, so the internal libavcodec order is used -> it matches the WAVEFORMATEXTENSIBLE order for all common channels (see above for 6.1 and 7.1) ------------------------------------------------------------------------------------------------- Then, regarding what the WAVEFORMATEXTENSIBLE order actually is: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757714(v=vs.85).a...

...). 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. >> 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: https://xiph.org/flac/changelog.html is incorrect. > The channel mask implicitly contains the number of channels; > but such...

Hi (again), I started to work on an ACM (Audio Compression Manager) for FLAC. I currently only have the canvas. The encoding/decoding is not done yet. So it's completely useless. But since the canvas is the harder thing to start, here it is. (just in case I don't have time to continue) http://mukoli.free.fr/flac-ACM.v0.1.0.zip

On Dec 14, 2014, at 10:02 AM, lvqcl <lvqcl.mail at gmail.com> wrote: > Currently the header of a decoded WAV file can be different to the > original WAV file because FLAC doesn't preserve 'fmt ' chunk. > > For example: create a 24-bit stereo .wav file with WAVEFORMATEXTENSIBLE > header with channel mask == 3. Encode it to .flac then decode back to .wav. > FLAC creates a 24-bit stereo .wav file with WAVEFORMATEX header. Did you try this when using the FLAC command-line option --keep-foreign-metadata? I did not write the code for that option, but I did write a prop...

...have a solution that can allow me to achieve my initial goal of compatibility. I can simple write a DirectShow source filter to read the FLAC file, then the ACM codec can treat the stream. And the AVIs with embedded FLAC audio will be readable in every Windows Platform. >Have you tried to use a WAVEFORMATEXTENSIBLE? This should make registration obsolete. I believe the WAVEFORMATEXTENSIBLE structure is available only for WDM audio drivers. Is it true? The WDM drivers are included with all the necessary functionality only in Windows 98SE or later. I think it's a big problem. What do you think? Regards, D...

...find any information about multi-channel support on xiph.org. I've used 'oggdropXPd' to encode a 5.1 wavefile and the Xiph OggVorbis libraries (vorbisfile.dll) to decode the file successfully, however the order of the channel interleaving is different to the original wave file (a 5.1 WAVEFORMATEXTENSIBLE file). Is the channel order specified for OggVorbis files, or is there a way I can retrieve this information from the file itself ? On a related note ... do any of the encoders assume that a particular channel contains LFE only ? Thanks for any help you can give me. Dan -------------- next par...

...14 Dec 2014 01:14:16 -0800 Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > > -------------------------- > > Also, I have a question. > > > > Currently flac complains about 24-bit .wav files if they have > > old WAVEFORMATEX header and not 'proper' WAVEFORMATEXTENSIBLE > > header. However it writes such files itself. > > > > Is it better to fix this so it decodes 24-bit .flac files to .wav > > files with WAVEFORMATEXTENSIBLE header? Or is it better to leave > > things as is (for better compatibility with old programs)? > > Th...

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

Hi Ingo, >It is just a WAVEFORMATEX with a GUID in it. For the ACM system it is just a format with the id >WAVE_FORMAT_EXTENSIBLE and since ACM drivers are not registered by wFormatTag it should be working. >For testing purposes I've written a Vorbis ACM driver, that uses a WAVEFORMATEXTENSIBLE and I experienced >a problem when opening files with Media Player. It spend quite some time at 100 % CPU doing nothing (from the >users perspective). However the problem might have come frome either the fact, that the driver was compression >only or that it collided with a DirectShow filte...

lvqcl wrote: > The commit http://git.xiph.org/?p=flac.git;a=commitdiff;h=99257e177eac96fa41a107b423080232f59ebe45 > also requires some changes in write_iff_headers() function: > > currently flac don't write WAVEFORMATEXTENSIBLE header if > decoder_session->channel_mask is equal to 0, 1 or 3. > After the commit 99257e17 flac should do this for channel_mask > equal to 0, 4 or 3. > > The patch fixes this. Applied, thanks. > -------------------------- > Also, I have a question. > > Currently...

...for FLAC. But since it's a 16 bits value, you can probably put anything randomly (only few are reserved). And I don't think it's illegal to use a number like that. Ingo Ralf Blum wrote: >>WAVEFORMATEX >>yes, that's the way to know what the codec does. >>But no WAVEFORMATEXTENSIBLE. on this one. As it's based on the work I >>did on Lame I discovered how to use this in lame. And so you can put as >>many data as you want in the WAV header, ie metadata. So it could be done >> > ! > > I thought this, since ACM has problems with WAVEFORMATEXTENSIBLE...

HI Josh, I'm starting now to compile the ACM codec. I don't know how long it will take, since I do it in my free time, but I guess it will not take to long. About Mark Powell's comment, with an ACM codec there will be a lot of Windows GUIs for FLAC. I'm writing this message to talk about the FLAC format. The GUIs for the Audio Codec Manager, including Winamp and Windows Media

Hi, This patch addresses the following issue: [Problem] MinGW build of flac command fails to parse piped WAV input with WAVEFORMATEXTENSIBLE format. [Description] This is because MinGW fseeko() doesn't return error for the attempt to seek on non seekable file (same behavior as MSVC). The simplest solution would be to change #ifdef _MSC_VER to #ifdef _WIN32 here. Instead, this patch tests file with fstat(), and use fseeko() only whe...

...code.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 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 */ + /* onl...

At the risk of throwing more fuel on the fire, I found the following document on the Microsoft website. It appears to be the file format counterpart to the API documentation presented by Chris Wolf. I'm not familiar with the WAVE format, so I'll let you guys interpret it (or tell me it is irrelevant): http://www.microsoft.com/HWDEV/audio/multichaud.htm [As an aside: Why does Microsoft

Hallo everybody, I just created a small patch for oggenc to be able to read and encode wav6-files. This files are of micro$ofts WAVEFORMATEXTENSIBLE format type and can contain multiple channels. a52dec can produce this type of file from ac3 streams. Might be it would be better to teach oggenc to read ac3 streams natively. There is probably a better way to encode low frequency channels contained in this files, but I'm not skilled enough t...

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

...smedia/howto/articles/Multichannel.aspx#link6 For some reason the channel mask was incorrectly set to 0x3f, so I manually changed it to 0x063f (this should be the correct mask for 7.1 eh?). Now trying to just throw that into the reference CLI I get the following error "8_Channel_ID.wav: ERROR: WAVEFORMATEXTENSIBLE chunk with unsupported channel mask=0x063F." That made exactly no sense whatsoever...how could that channel mask be unsupported when I've read time and time again that FLAC supports up to 8 channels. So after a bit of browsing through the 1.1.4 source, I found it myself in encode.c. All o...