similar to: FW: Odd number of samples in a stereo wave file

This topic is possibly more appropriate on the flac-dev list, since most flac users are not going to be interested in the details of WAVE format errors. Assuming it's ok to keep talking about it here... Ben, you've stumbled upon one of the common shortcomings of specifications. There are often assumptions which are not spelled out, or there are pieces which are vague. In some

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

<ben@yarwood.com> wrote: ... > 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 flac > encoder. There seemed to be confusion over what was actually wrong with the file but as Brian Willoughby deduced correctly, the > file had an odd number of samples in the data chunk and as it was a stereo file, this

On 16/11/2007, Brian Willoughby <brianw@sounds.wa.com> wrote: > It would actually be punitive to expect the flac code to expect and > adapt to nonsensical WAVE files. You say "punitive". I say it would be "reliable". One missing byte is a huge burden and nonsensical? People post on this list looking for solutions. They don't want to become experts in the WAV

On 9/26/07, Josh Coalson <xflac@yahoo.com> wrote: > --- Martin Leese <martin.leese@stanfordalumni.org> wrote: ... > > Where can I find more detail on what is a > > "non-audio" RIFF chunk? > > it is any riff chunk that is not "fmt " or "data" > > > Ambisonic ".amb" files are WAVE-EX files with > > a

"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

Not sure if this belongs here or in flac-dev. I am subscribed to both, so flop it over if fits better over there. Looking at the Changelog for FLAC 1.2.1 (17-Sep-2007), it says: "With the new --keep-foreign-metadata in flac, non-audio RIFF and AIFF chunks can be stored in FLAC files and recreated when decoding." Where can I find more detail on what is a

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

<LET OBJECT=STEAM DIRECTION=OFF> Here is an improved WAVE file loader for oggenc/oggdrop : int load_wave(char * filename,void * buffer) { fprintf(stderr,"unsupported WAVE file format !\n"); return -1; } It has the same functionality as the current code, but is shorter, has less ( zero ? ) bugs, is easier to maintain etc. </LET> I created a RIFF/WAVE ( commonly known

I am resending this ( for the third time, mispelled vorbis-dev-@xiph.org ), because the last time it didn't make it ( it didn't appear on the web archive at www.xiph.org , the archive of vorbis-list for the current month is broken BTW ) -------- Original Message -------- Subject: Re: [vorbis-dev] WAVE loader for oggenc and oggdrop Date: Wed, 01 Aug 2001 13:44:47 +0200 From: David Balazic

I'm reordering the code in ao_wav.c that writes wav files to prevent the problem we had earlier. If ogg123 was improperly terminated (Segfault, kill -9, etc.), the output wav file was not even recognizable because the header was totally blank. I have found that at the start of playback (from libao's perspective), I know all of the wav header info except two things: 1) The length of the

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

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

Hello. I'm running the swfdec-extract tool built from the 0.6.0 source tarball under gentoo and I'm finding that it's not able to rip the MP3s from the SWF file. I'm getting this: SWFDEC: ERROR: swfdec_codec_gst.c(269): swfdec_gst_decoder_init: failed to create decoder It manages to save the file as a WAV file, but I'd prefer the MP3 to get at the ID3 info in the file.

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 Sun, Jun 08, 2003 at 02:06:18AM +0200, Paul Seelig wrote: > This is what i get when trying to encode a WAV file: > > ------------- snip ----------------- > [pseelig]/tmp > flac -o YouGotMail.flac YouGotMail.wav > > flac 1.1.0, Copyright (C) 2000,2001,2002,2003 Josh Coalson > flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you > are welcome to

i had the problem is flac 1.1.2 so upgraded to 1.1.4 but now the problem is just different. the wav file is from audacity, so i guess it is culprit for setting that format type 1 bit, but shouldn't this still work? i found in 1.1.2 (before i found 1.1.3 had the odd size fix judging by relnotes) that i could add a dummy byte to the end and this seems to fix my issue, just not cleanly. here

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

that's why i asked the original poster if the files were odd size, i had that issue before with a 24 bit mono file and wrote this script to fix it: #!/bin/sh # # sfoddfix - Sound File ODD size FIXer # # NOTE: flac v1.1.2 pukes on files that have an odd byte count, this pads them files=${*:-*.wav} for file in $files do size=$(stat --printf='%s' $file) if [ $(($size%2)) -ne 0 ];

Okay.. I love flac but just had a rather serious failure that really shakes my confidence. It resulted in the near loss of a master audio recording. Fortunately, I have a backup. Though there may have been other cases where I have lost original material because I have been compressing a lot of originals and deleting them after doing a 'flac -t' on them. Basically, flac failed with a