From: martin r. <li...@ru...> - 2004-08-31 10:21:04
|
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 |