"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 program for linux that could automatically take these > bytes off, without running the risk of removing good data? Or is there a > way to get the flac converter to ignore this error and create the file? I'm > running flac 1.2.1 on Red Hat Enterprise Linux ES release 4.I am butting in here, but if these extra bytes are harmless then shouldn't this be a warning, not an error? I had a similar problem years ago with acoustic data. The data files were mounted from a computer running VMS using NFS. When viewed on a UNIX machine, the files had extra data after the (UNIX) logical end-of-file. -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web: http://members.tripod.com/martin_leese/
There is no such thing as "harmless extra bytes" in a .wav file. RIFF/WAVE is defined as a series of chunks, and there is no header at the beginning which indicates how many chunks to expect. A program reading a .wav will see these 2 extra bytes as a "Chunk Type" and that's why the confusion results. The program has no way of knowing that it should stop before the "extra" data. What people generally refer to in the literature as a .wav "header" is really not a header at all. It is just another chunk, one which can legally occur at more than one place in a WAV file, and it does not even have a count of chunks. There are a great number of programmers out there - even at prominent audio companies - who do not understand the finer points of file format design, and the situation is not helped by the poor availability of documentation on RIFF/WAVE. As a result, there are too many programs out there which create bad WAV files. The solution is to fix the bad programs and not bloat the good programs. If you really want to dig down deep into the details of RIFF/WAVE, there is actually a meta-chunk at the very beginning of the file which marks it as a RIFF file of subtype "WAVE" and this chunk length usually includes the rest of the file chunks. All remaining chunks are "inside" this meta-chunk. However, whether the extra two bytes are within this first meta-chunk, or beyond the end of the meta- chunk, it is still perfectly legal in each case for a chunk to follow. In other words, the meta-chunk must be precisely filled with whole chunks, not partials, and the meta-chunk must be followed by whole chunks until the end of the file. As Josh points out, adding extra code to FLAC to recover gracefully when a chunk starts with bad data would just add needlessly to the complexity of the code, and there would probably be a never-ending list of ways in which bad WAV files could go wrong. It's quite enough that FLAC supports the entire legal range of RIFF/WAVE files, there's no need to take on the larger task of also support illegal files. If you get a bad WAV file, use another program to fix it first, then FLAC will be ready to support it. Actually, FLAC does recover gracefully from these errors, it simply does not accept the WAV as valid, because that would be a very dangerous assumption to make in the face of an illegally-formatted file. Brian Willoughby Sound Consulting On Nov 1, 2007, at 15:38, Martin Leese wrote: "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 program for linux that could automatically take > these > bytes off, without running the risk of removing good data? Or is > there a > way to get the flac converter to ignore this error and create the > file? I'm > running flac 1.2.1 on Red Hat Enterprise Linux ES release 4.I am butting in here, but if these extra bytes are harmless then shouldn't this be a warning, not an error? I had a similar problem years ago with acoustic data. The data files were mounted from a computer running VMS using NFS. When viewed on a UNIX machine, the files had extra data after the (UNIX) logical end-of-file.
Hi Harry, I worked for Microsoft for 4 years, and have been programming audio software for 25 years (starting many years before WAV or RIFF was invented). If you want documentation, the most definitive source is the Microsoft Developers Network (MSDN). However, be warned that this is the most confusing set of documentation known to mankind. Every search returns redundant documentation split across multiple Windows and Windows-related products. I really wish they would clean this up, and document things in one place, rather than have multiples revisions and variations of the same information in multiple pages. Wikipedia has several links into msdn.microsoft.com that you could research. Internet searches are your friend. Brian Willoughby Sound Consulting On Nov 1, 2007, at 17:11, Harry Sack wrote: hi where did you find information about the wav format because you say there is poor documentation about it? can you point me to some websites or sources you used for this? thx
On Nov 1, 2007 6:11 PM, Harry Sack <tranzedude@gmail.com> wrote:> hi > > where did you find information about the wav format because you say > there is poor documentation about it? can you point me to some > websites or sources you used for this?I keep copies here: http://www.ambisonia.com/Members/mleese/file-formats/ As Brian points out, the Microsoft doc (1 of 5) is unreadable. The McGill University doc (5 of 5) is a lot more useful. Doc 2 of 5 might also be of interest; ignore the others. Regards, Martin -- Martin J Leese E-mail: martin.leese@stanfordalumni.org Web: http://members.tripod.com/martin_leese/
You're brilliant, Harry. Lame MT running on 2 threads runs at 120% while Lame (standard) running on 2 processes runs at 200%. If you still prefer only 120% over 200%, then you can continue to believe that multithreading this kind of algorithm is "smart" - I guess you weren't paying attention when folks on this mailing list suggested that you are far better off running FLAC multiple times on a multiprocessor machine compared to any small speedup you might get from multithreading. Brian On Nov 2, 2007, at 06:23, Harry Sack wrote: 2007/11/2, Brian Willoughby <brianw@sounds.wa.com>: I worked for Microsoft for 4 years, and have been programming audio software for 25 years (starting many years before WAV or RIFF was invented). haha, that explains why you give such stupid answers like 'making the encoder support multiple threads won't speed it up' while other encoders (like LAME MT) have nice speed boosts when doing this ... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/flac/attachments/20071102/5e91dc87/attachment.htm