[linux-audio-dev] libsndfile: type combinations and string data

martin rumori lists at rumori.de
Tue Aug 31 13:36:03 UTC 2004


On Tue, Aug 31, 2004 at 09:33:44PM +1000, Erik de Castro Lopo wrote:
> > yields me both an error.  is that supposed to return true?
> 
> For sf_format_check() to return TRUE, you MUST also set the sample
> rate, channel count and number of channels.

i see. thank you.  missed that in the test case...  o.k., now

SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_BIG succeeds, as well as
SF_FORMAT_WAV | SF_FORMAT_FLOAT | SF_ENDIAN_LITTLE, so the endian-ness
switches are like requests which could be fulfilled or not.

i am still wondering whether it wouldn't be useful to let
| SF_ENDIAN_CPU fail in the case it "resolves" to an invalid combination
but let it succeed in the other case.

in our foo sound synthesis language (scheme scripted), the user is
allowed to do:

(create-soundfile "test.aiff" 'aiff 'auto 48000 2)

where 'auto is an alternative way of specifying the sample format
(instead of 'short or 'float), and means: foo's native processing
sample type (currently float) in host byte order, SF_FORMAT_FLOAT |
SF_ENDIAN_CPU.  the user might expect that the above call works on
macintosh. while the call with 'wav should work on pc (and 'snd or 'au
should work everywhere, which is the case).

in order to allow 'aiff and 'wav in combination with 'auto, i could
check manually for the host byteorder and the formats before calling
libsndfile, but that feels like doubling efforts since those checks
are already done in libsndfile, except of the different return
behavior with SF_ENDIAN_CPU.

> Yes, and that should be possible. What is not possible is
> openning the file RDWR and modifying the string data in the 
> header.

agreed.

> > but still allowing to open files with comments in SF_RDWR
> > and to use the sf_writex_*() calls?  (currently possible with AIFF,
> > but not with WAV).
> 
> Are you sure?

quite sure.  the attached example yields:

libsndfile(open): Error : Cannot open file in read/write mode due to string data in header.

but maybe i am missing something again...

thanks a lot,

martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stringdata.c
Type: text/x-csrc
Size: 1183 bytes
Desc: stringdata.c
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20040831/192ac56e/attachment.c>


More information about the Linux-audio-dev mailing list