Hey everybody on the list,
i'm new on the list and with pd. The first problem i have is how to read floating point soundfiles. With samplitude i recorded soundfiles in floating point format. (my D/A converter does 24 bits); now i want to load in PD. I tried to load this soundfile with the element "soundfiler" but get a heather mistake. is it possible somehow to load a floating point soundfile in PD ?
greetns TOM
Hi Tom,
soundfiler only knows about "nextstep" floating-point soundfiles, but can read Wav and Aiff 24-bit fixed files too. I think there's a 23-bit floating point type defined fo Wav files, but I don't know what the header looks like; someday I hope to find this out and support it.
cheers Miller
On Mon, Jan 07, 2002 at 09:03:15PM +0100, thomas gorbach wrote:
Hey everybody on the list,
i'm new on the list and with pd. The first problem i have is how to read floating point soundfiles. With samplitude i recorded soundfiles in floating point format. (my D/A converter does 24 bits); now i want to load in PD. I tried to load this soundfile with the element "soundfiler" but get a heather mistake. is it possible somehow to load a floating point soundfile in PD ?
greetns TOM
WAVE 32bit floats is easy ; the wFormatTag field is 3 instead of 1, and the various bitspersample and blockAlign fields have to reflect the 32bit wordsize, as you woudl expect. You should use the WAVEFORMATEX form of the header, 18bytes long (the added 16bit word is zero; it gives the count of any extra bytes in the header, which would indicate a compressed format). 0dBFS value is 1.0; "over-range samples are allowed, and should be clipped by the rendering device".
Note that 32bit integer WAVE files are also possible (wFormatTag = 1 in the usual way).
AIFF-C floats is more complicated, but is also being supported more widely, so would be worth adding to PD some time. There is code in Csound now for both WAVE and AIFF-C floatsam files. Apple, bless them, don't specify 0dBFS, but it can be reliably understood to be 1.0 as well.
A while ago Tom Erbe and I (with encouragement from an audio person at Microsoft) defined a PEAK chunk specifially to go into floatsam files, (for WAVE, WAVE_EX, and AIFF-C), though it has convenience even with the integer formats; this has also recently been added to Csound. The PEAK chunk (together with the AIFF-C floats spec) is available from Tom's website:
http://shoko.calarts.edu/~tre/
If you want to get PD ~really~ up to date, you might consider adding some support for the new WAVE-FORMAT-EXTENSIBLE (WAVE-EX) format, which should really be used instead of WAVE for all high-resolution audio, and certainly for any low-level rendering code, for Windows systems with WDM drivers. It's other claim to fame is support for defined speaker feeds for surround sound. I have a fairly comprehensive web page for it at:
http://www.bath.ac.uk/~masjpf/NCD/researchdev/wave-ex/wave_ex.html
and will be publishing WAVE-EX handling code ere long, quite possibly for Csound. I would normally offer to do it myself for PD, but I am really swamped with projects at the moment, and just can't take on another one!
Richard Dobson
Miller Puckette wrote:
Hi Tom,
soundfiler only knows about "nextstep" floating-point soundfiles, but can read Wav and Aiff 24-bit fixed files too. I think there's a 23-bit floating point type defined fo Wav files, but I don't know what the header looks like; someday I hope to find this out and support it.
cheers Miller
hi Richard,
could you explain why Samplitude (checked with 6.0 `producer 2496') uses 16-byte headers for 32-bit float .wav files? I mean, is this a violation of the standard? How should we treat such cases?
Krzysztof
Richard Dobson wrote:
WAVE 32bit floats is easy ; the wFormatTag field is 3 instead of 1, and the various bitspersample and blockAlign fields have to reflect the 32bit wordsize, as you woudl expect. You should use the WAVEFORMATEX form of the header, 18bytes long (the added 16bit word is zero; it gives the count of any extra bytes in the header, which would indicate a compressed format). 0dBFS value is 1.0; "over-range samples are allowed, and should be clipped by the rendering device".
Slightly tricky question to answer solidly. Microsoft stipulate that the larger 18byte WAVEFORMATEX structure should be used for all non-PCM and compressed formats (which in practice includes floats); and all their examples show this. But as with so many aspects of RIFF, documentation is scattered and piecemeal. The floats format was developed in tandem by Sonic Foundry and Microsoft, and much of my information actually comes from the former.
More to the point, most commercial applications bend over backwards to open a file if they can - I have had files with known errors in the header (wrong data sizes, etc) be accepted by both Microsoft and third-party applications. On reading, of course, you can parse for both 16byte and 18byte format chunks, and this is what I do, and the majority of applications would do. The more interesting question thus would be if Samplitude will accept a floats file with the 18byte format chunk, which it should. But it is simply churlish, and no real help to the user, to be dognmatic on reading a file, when there is actually nothing to stop you accepting it. So the fact that an application will accept a format is no actual guarantee that the format is 100% correct - unless that is actually the stated purpose of the application in the first place.
So my answer is a bit Orwellian; both 16byte and 18byte chunks may be 'acceptable', but the latter is more correct than the former!
Richard Dobson
hi Richard,
thank you! You are right, it is better to conform, and to choose the 18-bit way in writing. Checked Samplitude and WaveLab -- both properly load 18-bit. But upon storing, Samplitude always uses 16-bit, even if the file was originally 18-bit. WaveLab does not save float files anyway. And no matter if 16-bit, or 18-bit, ProTools is always happy to report: ``This file is unreadable by ProTools''.
Krzysztof
Richard Dobson wrote: ...
More to the point, most commercial applications bend over backwards to open a file if they can - I have had files with known errors in the
hi Miller,
soundfiler would read 32-bit float .wav files quite willingly, if this possibility had not been blocked by rejecting their headers -- would you accept them, please?
Adding ``...else if (format == 32) bytespersamp = 4;'' option to .wav portion of open_soundfile() magically allows the soundfiler to correctly load such sounds, at least if they were recorded in Samplitude (I have not checked other editors). Why this works? Speaking in t_wave terms, soundfiler ignores w_fmttag (which is now equal 3), w_navgbytespersec and w_nblockalign fields, using only w_nbitspersample (equal 32) as a clue. All other fields are generic, and the original nextstep processing does the trick for sample data.
Btw, after taking closer look at soundfiler, I would like to know if anybody has been using it to load .wav files containing extra chunks before data chunk, such as recorded with WaveLab? I had not been so lucky (except in raw mode) without making little changes in the sources. With those changes soundfiler appears to gracefully skip unknown chunks and read all the remaining data (both 16, and 24-bit).
All of this applies also to readsf~. The changes are attached below.
Krzysztof
Miller Puckette wrote: ...
soundfiler only knows about "nextstep" floating-point soundfiles, but can read Wav and Aiff 24-bit fixed files too. I think there's a 23-bit floating point type defined fo Wav files, but I don't know what the header looks like; someday I hope to find this out and support it.
--- d_soundfile.c~ Thu Aug 23 18:23:37 2001 +++ d_soundfile.c Tue Jan 8 23:21:42 2002 @@ -254,20 +254,25 @@ bytespersamp = 2; else if (format == 24) bytespersamp = 3;
else if (format == 32)bytespersamp = 4; else goto badheader; headersize = sizeof(t_wave); while (strncmp(((t_wave *)buf)->w_datachunkid, "data", 4)) { /* extra chunk at beginning: try to skip it and pray */
long skip = swap4(((t_wave *)buf)->w_datachunksize, swap) + 4;
long skip = swap4(((t_wave *)buf)->w_datachunksize, swap);
+#ifdef DEBUG
post("skipping unknown chunk (0x%08lX bytes)", skip);
+#endif if ((skip < 4) || (lseek(fd, skip, SEEK_CUR) < 0)) { perror("lseek"); post("confused by extra chunks in wave header?"); goto badheader; }
headersize += skip;if (read(fd, buf, sizeof(t_wave)) < (int)sizeof(t_wave))
headersize += skip + 8;if (read(fd, ((t_wave *)buf)->w_datachunkid, 8) < 8) { perror("read"); post("couldn't read past extra chunks in wave header?");
Hmm, sounds like I should be spending a bit more time on this one..
I do believe I've got chunk-skipping going in my current version of Pd but it's much too unstable to release right now...
cheers Miller
On Wed, Jan 09, 2002 at 12:07:04PM +0100, Krzysztof Czaja wrote:
hi Miller,
soundfiler would read 32-bit float .wav files quite willingly, if this possibility had not been blocked by rejecting their headers -- would you accept them, please?
Adding ``...else if (format == 32) bytespersamp = 4;'' option to .wav portion of open_soundfile() magically allows the soundfiler to correctly load such sounds, at least if they were recorded in Samplitude (I have not checked other editors). Why this works? Speaking in t_wave terms, soundfiler ignores w_fmttag (which is now equal 3), w_navgbytespersec and w_nblockalign fields, using only w_nbitspersample (equal 32) as a clue. All other fields are generic, and the original nextstep processing does the trick for sample data.
Btw, after taking closer look at soundfiler, I would like to know if anybody has been using it to load .wav files containing extra chunks before data chunk, such as recorded with WaveLab? I had not been so lucky (except in raw mode) without making little changes in the sources. With those changes soundfiler appears to gracefully skip unknown chunks and read all the remaining data (both 16, and 24-bit).
-
Krzysztof Czaja -
Miller Puckette -
Richard Dobson -
thomas gorbach