similar to: [PATCH] Fix for odd RIFF size

Brian Willoughby wrote: > The ckSize field can be odd to represent the size of the valid data. > > However, the chunk itself must always be an even size. This requires a padding byte at the end of a chunk before the next chunk can begin, or before the end of file. The latter case is the one that most often occurs in buggy RIFF writing programs - the last chunk will have an odd ckSize and

The ckSize field can be odd to represent the size of the valid data. However, the chunk itself must always be an even size. This requires a padding byte at the end of a chunk before the next chunk can begin, or before the end of file. The latter case is the one that most often occurs in buggy RIFF writing programs - the last chunk will have an odd ckSize and the file will be one byte shorter than

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'm new to the mailing list but am interested in picking up a thread from earlier in the month but which I thought had become confusing so I am starting again. I should admit from the beginning that I am a colleague of Alex Brims who started the original thread. The thread in question related to a wav file with an extra two bytes at the end causing a partial sample error in the reference

just recently I have finished implementing support for saving non-audio chunks in RIFF WAVE and AIFF with the FLAC file in application metadata blocks, and restoring them when decoding. you can read about more about it here: http://www.hydrogenaudio.org/forums/index.php?showtopic=56968 the zip file there has windows binaries; CVS HEAD has everything checked in if you need a different platform.

So i'm trying to write an app that enocodes WAV files to "Ogg in a RIFF-WAV" files. Theese are used in Fruity Loops, and since the software itself does not have this feature i wanted to write one myself. The point for it is to save space when sharing "zipped loop packages". Such packages contain the samples (WAV) and the song file (FLP). At first i wrote just an encoder

"Alex Brims" <alex.brims@gmail.com> wrote: > Ok, we actually worked this out - there were 2 extra bytes doing nothing at > the end of the files. Opening the file in SoundForge and saving it (without > changing it) took off the extra bytes and allowed the file to convert to > FLAC. > > Thanks to everyone who emailed me suggestions. > > Is there a decent

Erik de Castro Lopo wrote: > Err, thats a link to a post talking about flac's WAV reader being limited > to 4Gig files. Problem is, *all* WAV files greater than 4Gig are mal-formed. > Due to limitations in the way WAV files are specified, no valid WAV file > can ever be over 4Gig. And most don't work over 2 GB. The solution we (Xiph) have used in other projects (opusenc,

stream_encoder.c has the following code: /* try to keep qlp coeff precision such that only 32-bit math is required for decode of <=16bps streams */ if(subframe_bps <= 16) { ... But FLAC can convert 16-bit input to 17-bit if mid-side coding is used. So, does it make sense to compare subframe_bps with 17? (The patch is attached. What do you think about it?) -------------- next part

About the removed assert in this commit: http://git.xiph.org/?p=flac.git;a=commitdiff;h=bc5113007a53be2c621d5eb5f4485eddf947ef37 It looks reasonable that if x.num_comments == 0 then x.comments is also NULL. Otherwise there's probably a leak somewhere that should be fixed. I found several places where the situation is reverse: comments can be 0 but num_comments is not; IMHO it makes sense

MSVS profiler shows that the following code in stream_encoder.c takes several percent of CPU time: for(rice_parameter = 0, k = partition_samples; k < mean; rice_parameter++, k <<= 1) ; this code is equivalent to: rice_parameter = 0; k = partition_samples; while(k < mean) { rice_parameter++; k <<= 1; } The idea was to accelerate it:

Hi All, Why is it that sometimes when I encode a .wav file then decode it again the length of the generated file is 2 bytes shorter than the length of the source file? The discrepancy in length occurs in the header and the remainder of the data from there on is identical. It seems to me that what appear to be length fields in the header is adjusted appropriately. I suspect that this is not a

> Why is it that sometimes when I encode a .wav file then decode it again > the length of the generated file is 2 bytes shorter than the length of > the source file? > > The discrepancy in length occurs in the header and the remainder of the > data from there on is identical. It seems to me that what appear to be > length fields in the header is adjusted appropriately.

(2013/03/05 12:27), Cristian Rodr?guez wrote: > Nothing against you code, that's ugly ..but as it is a first step it can > be forgiven :-) > > I will just force flac to be built with 64 bit file offsets and just > reject any caller trying to include/link libflac into a non-lfs program > like > > http://ac-archive.sourceforge.net/largefile/off_t_headers.html > >

On 3/22/07, Brian Willoughby <brianw@sounds.wa.com> wrote: ... > But to return to your question, exactly what kind of "support" are > you looking for? I wasn't looking for any particular support, but just to see what support was there (if any). ... > I do not believe that there is any need for code specifically > supporting Ambisonics. FLAC supports conversion to

On 12/08/16 12:24 AM, Thomas Zander wrote: > On 7 December 2016 at 21:08, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: >> lvqcl.mail wrote: >> >>> "make -f Makefile.lite" also doesn't work out of box. >> >> Didn't work for the 1.3.1 release either. Makes me wonder why we even >> keep it around. > > Because it works on

lvqcl wrote: > I have a couple of questions: > > 1) Do you plan to release 1.3.1 pre1, pre2 etc or just 1.3.1 w/o any pre-releases? I had not planned to do a pre-release. > 2) Do you plan to release any official binaries (flac, metaflac, maybe something else)? Nor had I planned to release binaries. The source code tarball ends up here: https://svn.xiph.org/releases/flac/ I

Brian Willoughby <brianw at audiobanshee.com> ?????(?) ? ????? ?????? Sun, 31 Jan 2016 22:26:40 +0300: > My assumption is that the code was written to call flac_fopen() so that it is portable to every operating system, even those without fopen(). If you replace flac_fopen() with fopen(), then the tests won't compile on systems that don't have fopen(). I REALLY doubt it. Even if

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

test_streams currently depends on grabbag and (on Windows) on win_utf8_io libs. It depends on win_utf8_io only because it uses flac_fopen() function. It will become to depend on libFLAC when all file functions will be moved from win_utf8_io to libFLAC. Not a big problem, but it is possible to avoid this dependency by replacing flac_fopen() with fopen(). test_streams doesn't open/create