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

martin rumori lists at rumori.de
Tue Aug 31 04:30:41 UTC 2004


On Tue, Aug 31, 2004 at 07:54:58AM +1000, Erik de Castro Lopo wrote:
> SF_ENDIAN_CPU really only makes sense when the file format allows
> bot endian-nesses.

ahh, i see, the SF_ENDIAN_* format parameters are meant to FORCE to a
specific endian-ness, and with formats supporting just one endian-ness
forcing does not make sense at all.

i was thinking of it like REQUESTING a specific endian-ness,
which would yield an error in
SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_LITTLE
but would proceed in 
SF_FORMAT_AIFF | SF_FORMAT_FLOAT | SF_ENDIAN_BIG.
i understood SF_ENDIAN_CPU like "resolving" to one of SF_ENDIAN_LITTLE
or _BIG depending on the current platform, that's why my question...

> AIFF amd WAV only allows one endian-ness for float data, while AU
> allows both. AIFF is a little strange in that it does allow both
> endian-nesses for PCM ints.

but, with 1.0.10 and 1.0.11pre4,

  SF_INFO info;

  info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_LITTLE;
  if (! sf_format_check(&info))
    {
      printf("AIFF | LITTLE invalid\n");
    }

  info.format = SF_FORMAT_AIFF | SF_FORMAT_PCM_16 | SF_ENDIAN_BIG;
  if (! sf_format_check(&info))
    {
      printf("AIFF | BIG invalid\n");
    }

yields me both an error.  is that supposed to return true?

> > snd does not explicitly allow using string data in the file format.
> > however, i remember that it was done in the old NeXT days by
> > increasing the data offset and using the space in between for a
> > comment.  do you think this could be implemented in libsndfile for the
> > SF_STR_COMMENT thing or is that just too non-standard?
> 
> Do you mean for the AU file format?

yes, sorry.

> > with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
> > mode.  
> 
> There are good reasons for this. Say you already have a comment in
> the head which is 10 bytes long. You now open the file in RDWR mode
> and change that comment header to be 16 bytes long. Fixing that is
> completely non-trivial.

i see.  maybe you'd had to move the data back in order to create space
for the comment.  not worth the work, agreed.

> > the call to sf_set_string() succeeds, but the actual data in
> > the file is not changed.  the call to sf_set_string() succeeds even
> > when the file is in SFM_READ mode.
> 
> Thats probably a bug.
> 
> > with SF_FORMAT_WAV, a file with string data can't be opened with
> > SFM_RDWR anymore.  this means there is no way to change the audio data

> As above.

i don't know too much about the data organisation in .aiff and .wav,
but if the comment is located in the head of the file, it could still
be possible to write/change the data section in SFM_RDWR.  what do you
think about letting sf_set_string() fail in any other mode than
SFM_WRITE, 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).

bests,

martin



More information about the Linux-audio-dev mailing list