Erik de Castro Lopo <erikd@mega-nerd.com> writes:

> Richard Dobson wrote:
>
>> It's so dead (or still-born) it doesn't show up at all on my ISP news
>> server, though plenty of com.soft-sys ones are. There is the
>> octave-maintainers list, with whom I see Erik is already in dialogue.
>
> Yep. It turns out that it is much easier to build external Octave
> modules than it used to be when I last looked.
>
> That means, that I can probably dump the three .m files I have in
> the Octave directory of the libsndfile tarball now and replace it
> with code to generate a binary octave module (.oct) to whatever
> is necessary.
>
> Then I just have to get all the Linux distro package maintainers to
> make sure to build a sndfile-octave package.
>
>> Can test, of course.
>
> I should have something for you by next week (big hacking day planned
> for Saturday).
>
> Erik

Thank you for your contributions, Eric. I'm a heavy user of octave.
-- 
%  Randy Yates                  % "My Shangri-la has gone away, fading like 
%% Fuquay-Varina, NC            %  the Beatles on 'Hey Jude'" 
%%% 919-577-9882                %  
%%%% <yates@ieee.org>           % 'Shangri-La', *A New World Record*, ELO
http://home.earthlink.net/~yatescr

Richard Dobson wrote:

> It's so dead (or still-born) it doesn't show up at all on my ISP news
> server, though plenty of com.soft-sys ones are. There is the
> octave-maintainers list, with whom I see Erik is already in dialogue.

Yep. It turns out that it is much easier to build external Octave
modules than it used to be when I last looked.

That means, that I can probably dump the three .m files I have in
the Octave directory of the libsndfile tarball now and replace it
with code to generate a binary octave module (.oct) to whatever
is necessary.

Then I just have to get all the Linux distro package maintainers to
make sure to build a sndfile-octave package.

> Can test, of course.

I should have something for you by next week (big hacking day planned
for Saturday).

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"All great truths begin as blasphemies."
-- George Bernard Shaw

Randy Yates wrote:
..
> 
> I hate to say it since the group is so dead, but there is an octave newsgroup:
> 
>   comp.soft-sys.octave 
> 

It's so dead (or still-born) it doesn't show up at all on my ISP news 
server, though plenty of com.soft-sys ones are. There is the 
octave-maintainers list, with whom I see Eric is already in dialogue. I 
am too much of a novice with octave (and even more so with matlab!), to 
be in a position to contribute. Can test, of course.

Richard Dobson

Richard Dobson <richarddobson@blueyonder.co.uk> writes:

> Erik de Castro Lopo wrote:
> ..
>> About a decade ago I suggested to John Eaton that libsndfile be used
>> to read audio file. Since libsndfile now does FLAC and Ogg/Vorbis (not
>> publically released yet), it might be time to try this again.
>>
> ..
>> Good luck adding FLAC and Ogg/Vorbis support in pure Matlab/Octave
>> code :-).
>
> Well, it's not such an unlikely thought; not least since matlab or
> octave may well have been used to develop the dsp for those
> formats. However, just having full WAVE and AIFF/AIFC PCM support
> would be very useful. Even AIFF becomes more moot every day, what with
> Macs now all on Intel, so that AIFF is no longer even the "native"
> format (and IMO has little else to commend it).
>
>> I really do thing its time to push for Octave to do audio file
>> reading via libsndfile whereever libsndfile is available.
>>
>
>
> I agree. the question is, how? Ostensibly it would have to be an
> app-level builtin function, not a m-file. How much format info to
> return to the caller, and in what way (I would want for example the
> WAVEX channel mask at the very least so I can process/create various
> multi-channel files, and PEAK chunk support). There is separate code
> for au files  ("au.m. auload.m etc), suggesting that the Matlab/octave
> way is to have separate commands for each primary format type. There
> is therefore an API to be designed that gets as much out of libsndfile
> as is practicable, into Octave-ese. Ineluctably, you may well be the
> person best placed to do this; and once done, who knows - maybe the
> Mathworks will be happy to negotiate a licence for Matlab, just as
> they do for fftw etc.
>
> In the short term, there is still a need to know how to hack wavread
> and wavwrite (I had to do it just to get endianness handled properly
> on the PPC Mac), so discussing the perils of soundfile format handling
> is still an unavoidable activity, sometimes!
>
>
> Richard Dobson

I hate to say it since the group is so dead, but there is an octave newsgroup:

  comp.soft-sys.octave 

--Randy


-- 
%  Randy Yates                  % "She has an IQ of 1001, she has a jumpsuit
%% Fuquay-Varina, NC            %            on, and she's also a telephone."
%%% 919-577-9882                % 
%%%% <yates@ieee.org>           %        'Yours Truly, 2095', *Time*, ELO   
http://home.earthlink.net/~yatescr

Erik de Castro Lopo wrote:
..
> 
> About a decade ago I suggested to John Eaton that libsndfile be used
> to read audio file. Since libsndfile now does FLAC and Ogg/Vorbis (not
> publically released yet), it might be time to try this again.
> 
..
> 
> Good luck adding FLAC and Ogg/Vorbis support in pure Matlab/Octave
> code :-).

Well, it's not such an unlikely thought; not least since matlab or 
octave may well have been used to develop the dsp for those formats. 
However, just having full WAVE and AIFF/AIFC PCM support would be very 
useful. Even AIFF becomes more moot every day, what with Macs now all on 
Intel, so that AIFF is no longer even the "native" format (and IMO has 
little else to commend it).

> 
> I really do thing its time to push for Octave to do audio file
> reading via libsndfile whereever libsndfile is available.
> 

I agree. the question is, how? Ostensibly it would have to be an 
app-level builtin function, not a m-file. How much format info to return 
to the caller, and in what way (I would want for example the WAVEX 
channel mask at the very least so I can process/create various 
multi-channel files, and PEAK chunk support). There is separate code for 
au files  ("au.m. auload.m etc), suggesting that the Matlab/octave way 
is to have separate commands for each primary format type. There is 
therefore an API to be designed that gets as much out of libsndfile as 
is practicable, into Octave-ese. Ineluctably, you may well be the person 
best placed to do this; and once done, who knows - maybe the Mathworks 
will be happy to negotiate a licence for Matlab, just as they do for 
fftw etc.

In the short term, there is still a need to know how to hack wavread and 
wavwrite (I had to do it just to get endianness handled properly on the 
PPC Mac), so discussing the perils of soundfile format handling is still 
an unavoidable activity, sometimes!

Richard Dobson

Richard Dobson wrote:

> Since you are here and it's reasonably on-topic -  your octave scripts
> as supplied with libsndfile (and inside the most recent OSX octave.app
> bundle),  seem to only read/write Matlab 5 MAT files using the "load"
> command, not soundfiles as such.

Yes, I would like to do something more, but its hard to do it in a 
cross platform way.

I get around this by using sndfile-convert (in the example directory)
to convert from anything else to mat5 format.

> Is there a cross-platform libsndfile 
> wrapper for octave and Matlab that does read and write wave and aiff
> files (at least), with control over sample format?

Not that I know of.

About a decade ago I suggested to John Eaton that libsndfile be used
to read audio file. Since libsndfile now does FLAC and Ogg/Vorbis (not
publically released yet), it might be time to try this again.

> It has always seemed that the only way to read and write more file
> formats, and more correctly, has been and is to edit wavread.m
> accordingly.

Good luck adding FLAC and Ogg/Vorbis support in pure Matlab/Octave
code :-).

I really do thing its time to push for Octave to do audio file
reading via libsndfile whereever libsndfile is available.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"I once worked for a company where as part of the BS5750 "Quality"
process I attended a meeting where I was informed that it was Company
Policy not to use free software. When I asked him for his written
authorisation for me to remove X Windows from our Sun workstations,
he backtracked."   -- Phil Hunt

Erik de Castro Lopo wrote:
..
> 
> If people want to spend considerable amounts of time writing code
> to read WAV files when something like:
> 
>     http://www.mega-nerd.com/libsndfile/
> 
> already exists, then thats fine by me, but please, please, 
> PLEASE do not write code to create WAV files 
...

Absolutely; but I was writing with respect to the suggested 
octave/matlab script, where the long-established builtin command is 
"wavread" (no question of supporting anything else but WAVE, it seems).
Many (including me) would like not to have to change scripts to use a 
new function, but just have wavread work for more WAVE formats. There is 
a gazillion audio-oriented scripts out there that all use wavread.

Since you are here and it's reasonably on-topic -  your octave scripts 
as supplied with libsndfile (and inside the most recent OSX octave.app 
bundle),  seem to only read/write Matlab 5 MAT files using the "load" 
command, not soundfiles as such. Is there a cross-platform libsndfile 
wrapper for octave and Matlab that does read and write wave and aiff 
files (at least), with control over sample format? I could use that 
myself right now as it happens!

It has always seemed that the only way to read and write more file 
formats, and more correctly, has been and is to edit wavread.m 
accordingly. Or, put another way, for complete portability, all 
soundfile parsing has to be written in octave/matlab language, not C. In 
which case, those doing the editing do need to know what the issues and 
gotchas are!

Richard Dobson

Richard Dobson wrote:

> WAVEFORMATEXTENSIBLE is documented here:
> 
> http://www.microsoft.com/whdc/device/audio/multichaud.mspx
> 
> And I have a placed a copy of the original RIFFMCI document here:
> 
> http://people.bath.ac.uk/masrwd/riffmcidoc.zip

If people want to spend considerable amounts of time writing code
to read WAV files when something like:

    http://www.mega-nerd.com/libsndfile/

already exists, then thats fine by me, but please, please, 
PLEASE do not write code to create WAV files because you will
almost certainly get it wrong and if your software becomes
widely used I will have to add yet more workarounds to 
libsndfile so that it accepts the broken files you create.

Please note that libsndfile is released under the GNU Lesser
Gerneal Public License allowing it to be used in Open Source,
shareware and closed proprietary programs. The *only* minor
restrictions are :

  - You must link to libsndfile as a DLL (windows), shared 
    library (unix) or dynlib (Mac OSX).
  - Provide a text document with your program that specifies
    your program uses libsndfile and that libsndfile is released
    under the GNU LGPL.
  - Provide a copy of the GNU LGPL.

Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
Moore's Law: hardware speed doubles every 18 months
Gates' Law: software speed halves every 18 months

David Lee wrote:
..
> 
> The problem is that a file can also contain any number of additional 
> application-specific labelled chunks (and sub-chunks) and the chunks can 
> appear in any order. 

They are not necessarily application-specific (there is a formally 
defined APPL chunk for this); many are chunks defined by microsoft; 
others by standards bodeis such as the EBU (for the Broadcast WAVE 
format etc).

An intelligent programmer will write the standard
> chunks in the conventional order, as above, and add any proprietory 
> chunks to the end of the file

There is an importnat destinction between truly "proprietary" chunks, 
and auxiliary standard chunks that are defined mostly by Microsoft for 
use in all files. There are many such chunks (e.g. defining information 
for use in samplers, such as root frequency, looping points) that do 
need (if present) to be supplied before the data chunk. One practical 
reason is that WAVE files are designed to be streamable (e.g. through a 
unix-style pipe to another process or more generally over a network, and 
you definitely do not want to wait for the data chunk to complete before 
reading that information).

> 
> Another nasty little gotcha is that the FORMAT chunk of a RIFF file can 
> legally contain several bytes of extra application-specific parameters 
> tacked on the end of the fmt sub-chunk, preceded by a two-byte integer 
> defining the number of extra bytes. Extra bytes are not supposed be used 
> in a WAVE file 

Not so. The 18byte WAVEFORMATEX form is mandated by Microsoft for 
Floating-point files (wFormatTag=3). For any compressed audio data, a 
FACT chunk must also follow the format chunk; Microsoft did concede that 
this was not required (but is still optional) for Type-3 floating-point. 
All parsing code must be prepared to find at least either of the 16 and 
18byte format chunks; and beyond that be able to read the 
WAVEFORMATEXTENSIBLE format which is required for all high-resolution 
formats (> stereo, >16bits). As I mentioned in another mail in this 
thread, that extends the format chunk to 40 bytes.

I also contributed to the definition of the PEAK chunk, which gives the 
value and position of the largest sample in each channel; this is also 
mandated to precede the data chunk, not least as the information can be 
use to rescale any floating-point files whose amplitude exceeds +-1.0. 
We use this in Csound, for example. See 
http://music.calarts.edu/~tre/PeakChunk.html for the details.

> 
> A couple of detailed descriptions of the WAV file format that helped me 
> to write my own parsing software are to be found at:
> http://ccrma.stanford.edu/CCRMA/Courses/422/projects/WaveFormat/
> http://technology.niagarac.on.ca/courses/ctec1631/WavFileFormat.html
> 

These are unfortunaly both far from complete or up-to-date descriptions. 
Part of the problem is that documentation on more recent elements is 
generally confined to Microsoft developer documentation, so many 3rd 
party developers are relying on what is almost obsolete information.

WAVEFORMATEXTENSIBLE is documented here:

http://www.microsoft.com/whdc/device/audio/multichaud.mspx

And I have a placed a copy of the original RIFFMCI document here:

http://people.bath.ac.uk/masrwd/riffmcidoc.zip

Richard Dobson