similar to: [PATCH] for flac/decode.c

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

On Sun, 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. > > >

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

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

Hi, >That's what I wanted to say a month ago. Mr. Blum, I'm really sorry for misunderstanding you. My mistake. I choose an ACM codec because it's the only option that works on every Windows Platform, and since the DirectShow has a generic wrapper that allows it to use ACM codecs, it appeared a good idea. I didn't note that the file format was going to be a problem. But I think

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

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,

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

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

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

Yep, that's the bad news, you need an ID from Microsoft to make sure this ID is only used 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

Now that we've selected a channel mapping for 7 and 8 channel flac, the command-line encoder tools needs updating to accept wav files with compatible channel maps. -r -------------- next part --------------

Removed buffer size increase. Only tells the filesize to Windows now. On 26.9.2014 14:08, Erik de Castro Lopo wrote: > Martijn van Beurden wrote: > >> Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently >> memory usage of FLAC decoding is about 1MB, so this patch is >> increasing memory usage tenfold, also for platforms that do not >> need this. It is a

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

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

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

This commit accepts the new default channel masks for 6.1 and 7.1 surround input WAV files, and writes the corresponding masks when decoding to WAV without a channel mask from the metadata block. --- src/flac/decode.c | 5 +++++ src/flac/encode.c | 4 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/src/flac/decode.c b/src/flac/decode.c index 98fc430..2d1bdd6 100644 ---

On 13-03-01 2:17 PM, Erik de Castro Lopo wrote: > Ralph, looks like there's a missing closing brace there. Do you want to fix > it and resubmit or should I fix it? Sorry about that. Is this one better? -r -------------- next part -------------- commit 93d92eb5e98cacd8cab185a0bfdaafb795b14b22 Author: Ralph Giles <giles at mozilla.com> Date: Thu Jan 17 16:21:45 2013 -0800

Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently memory usage of FLAC decoding is about 1MB, so this patch is increasing memory usage tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. Op 26-09-14 om 10:36 schreef Janne Hyv?rinen: > I made some changes to the previous patch. I don't know why I > originally didn't put the

Decoding flac files is also prone to producing fragmented files. NTFS has the ability to completely avoid fragmentation if it is told the file size before hand, but that would require using special Windows-only functions. Increasing the write buffer from the default 512 bytes to 10 MB already reduces the problem tremendously. -------------- next part -------------- diff --git