Reading a .wav file
in [Fortran]
|
Prev: How to Determine Highest Precision Available on a PC ??
Next: gcc4.4: f951: warning: command line option "-MM" is valid for C/C++/Java/ObjC/ObjC++ but not for Fortran
From: glen herrmannsfeldt on 11 Aug 2010 19:15 tholen(a)antispam.ham wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: >> Mohammed Anwer <manwer(a)gmail.com> wrote: >>> This may already have been answer many times on this forum. Can anyone >>> point me to an example program that reads/writes an audio .wav file? >> I have some C programs that can read/write them. There is some >> information in the header, otherwise some just remove the appropriate >> number of bytes and expect pairs of 16 bit words. > As I understand it, the various chunks can appear in any order and > still be standard-conforming. However, I have never encountered a > WAV file that didn't have all the format information at the head of > a file, with the data chunk coming last, so that streaming could be > supported. If the format information came after the data, one would > be forced to download all the data before knowing how to play it > properly. The usual form of PDF has much of the descriptive data at the end, at least the table of contents is at the end. I originally wrote some programs to read the Edirol R1 output, and found that they also read the Tascam DR-1 output. > There are a lot of digital audio recorders out there now that > support 24-bit samples, so I wouldn't be quite so certain about > expecting pairs of 16-bit words. It is cdrecord that seems to be documented as doing that. It requries 16 bit 44.1kHz data, with or without header. > I recently tested Linux's > support for these deeper bit depths by plugging in a digital > audio recorder to a computer via its USB port and then using > the file browser to look at the contents of the recorder's > memory. Hovering the mouse over a WAV icon causes Linux to > play the file, and it had no trouble playing a 24-bit 96 kHz > recording. Try it with cdrecord. Windows media player can also play 24 bit data, at least at 44.1kHz. > Too bad there is no native 24-bit integer type in Fortran. Because of alignment and endianness you pretty much want to extract it byte by byte anyway. > You > need to read such a file either as 3-byte character strings or > as a set of three 1-byte integers. For stereo, the samples are > interleaved. The WAV format allows for more than two channels, > though I have yet to encounter a WAV file that uses the > capability. In fact, I have a digital audio recorder that can > record four channels simultaneously, and rather than using a > single WAV file with the number of channels set to four, it > instead writes two stereo WAV files. Go figure. It seems likely that not so many will know what to do with that. I do wonder about monaural data, though. -- glen
From: glen herrmannsfeldt on 11 Aug 2010 19:17 dpb <none(a)non.net> wrote: > tholen(a)antispam.ham wrote: >> Too bad there is no native 24-bit integer type in Fortran. ... > Which language(s) do? Well, there isn't anything in Fortran against a 24bit data type. There are some processors with a native 24 bit type, and I believe that the compilers for those processors support 24 bits. -- glen
From: glen herrmannsfeldt on 11 Aug 2010 19:23 Ron Shepard <ron-shepard(a)nospam.comcast.net> wrote: (snip) > Considering some of the sophisticated, abstract stuff that did make it > through the language committees over the years (not just in fortran, but > other languages too), it is sort of surprising that something as > "simple" as bit-string processing hasn't made it into any of the popular > languages. I suppose PL/I isn't popular enough. All the character string operations also apply to bit strings. Relational operators generate BIT(1) results, and IF expects a bit string. On most systems, though, operations on bit strings are very slow. Using the bitwise operators in C (or Fortran) doing things one word at a time is often pretty fast. > On the other hand, it took 13 years (f77 to f90) before even > bit operators on integers were standardized in fortran, despite the fact > that the mil-std document on which that part of the f90 standard was > based was published in 1978 immediately after the f77 standard was > approved. Why not start counting in 1966, and call it 24 years? -- glen
From: tholen on 11 Aug 2010 19:30 dpb <none(a)non.net> writes: >> Too bad there is no native 24-bit integer type in Fortran. ... > Which language(s) do? There are so many languages out there now, and I have familiarity with so few of them, that I'm not in a position to answer that question. My point is that there are data files out there with 24-bit integers in them, and it would be nice to have a programming language that can read and write them painlessly. Because I know Fortran so well, my preference would be for Fortran to have that capability, otherwise I'd have to learn a new programming language. But I've jumped through the hoops and have Fortran code that can read a WAV file with 24-bit samples, storing the data in memory using 32-bit integers. What I have yet to write is code that can take those 32-bit integers, after some editing, and create a WAV file with 24-bit integers (or 16-bits, if writing to CD is the intent).
From: tholen on 11 Aug 2010 19:52
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> writes: >>> Mohammed Anwer <manwer(a)gmail.com> wrote: >>>> This may already have been answer many times on this forum. Can anyone >>>> point me to an example program that reads/writes an audio .wav file? >>> I have some C programs that can read/write them. There is some >>> information in the header, otherwise some just remove the appropriate >>> number of bytes and expect pairs of 16 bit words. >> As I understand it, the various chunks can appear in any order and >> still be standard-conforming. However, I have never encountered a >> WAV file that didn't have all the format information at the head of >> a file, with the data chunk coming last, so that streaming could be >> supported. If the format information came after the data, one would >> be forced to download all the data before knowing how to play it >> properly. > The usual form of PDF has much of the descriptive data at > the end, at least the table of contents is at the end. Should be okay, unless one needs to stream PDF over the Internet. > I originally wrote some programs to read the Edirol R1 output, > and found that they also read the Tascam DR-1 output. My code has successfully read WAV files generated by Zoom, Sony, Marantz, and some of unknown origin provided to me. But my code wasn't designed to read streaming data. It just keeps reading chunks until it gets to the end of the file, so if it were to encounter an oddball WAV file with the format chunk after the data chunk, my code should still be able to deal with it. >> There are a lot of digital audio recorders out there now that >> support 24-bit samples, so I wouldn't be quite so certain about >> expecting pairs of 16-bit words. > It is cdrecord that seems to be documented as doing that. > It requries 16 bit 44.1kHz data, with or without header. Not too surprising, considering that the CD standard is 16-bit 44.1 kHz data. But as flash memory prices continue to plummet, I think the days of spinning media are numbered. When they can get the cost of a 32 GB SDHC card down to the cost of a BluRay disc, why distribute an HD movie on BluRay? The SDHC card is smaller and impervious to the scratches on the optical surface (because it doesn't have one!). >> I recently tested Linux's >> support for these deeper bit depths by plugging in a digital >> audio recorder to a computer via its USB port and then using >> the file browser to look at the contents of the recorder's >> memory. Hovering the mouse over a WAV icon causes Linux to >> play the file, and it had no trouble playing a 24-bit 96 kHz >> recording. > Try it with cdrecord. Windows media player can also play > 24 bit data, at least at 44.1kHz. Will do. Might have tried it some time ago, but don't remember the result. >> Too bad there is no native 24-bit integer type in Fortran. > Because of alignment and endianness you pretty much want to > extract it byte by byte anyway. Fortunately, WAV files are little endian, and so is my PC hardware, so I've not needed to do any byte swapping. However, the other data format that I deal with frequently, namely FITS, is big endian, and I don't know what I'd do without a compiler that supports CONVERT='LITTLE_ENDIAN". (Well, I do know, but I'd rather not have to jump through those hoops.) >> You >> need to read such a file either as 3-byte character strings or >> as a set of three 1-byte integers. For stereo, the samples are >> interleaved. The WAV format allows for more than two channels, >> though I have yet to encounter a WAV file that uses the >> capability. In fact, I have a digital audio recorder that can >> record four channels simultaneously, and rather than using a >> single WAV file with the number of channels set to four, it >> instead writes two stereo WAV files. Go figure. > It seems likely that not so many will know what to do with that. > I do wonder about monaural data, though. The device itself has a built-in mixer, so one can reduce it to two channels. My code would deal with it by reading one of the files into memory as the main waveform, and then I can load the other file into what I call "scrap memory", and which point I can perform mixing. As for monaural data, my production code issues a message indicating that it wasn't designed to work on monaural data. The sample code that can read 24-bit samples does support reading monaural data. |