30 Aug
2004
30 Aug
'04
6:14 p.m.
hi erik,
i've got a question regarding type combinations in libsndfile:
SF_FORMAT_FLOAT | SF_ENDIAN_CPU works with SF_FORMAT_AU on any
platform, which is great. but it doesn't work with neither aiff nor
wav. i expected that it would work with one of the both formats,
depending on the host endianess.
is there a special reason why it does not?
some other questions regarding string data:
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?
with SF_FORMAT_AIFF, i can't write string data to the file in SFM_RDWR
mode. 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.
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
or the comment of the file without copying it? i guess there is a
special reason for that...
thanks very much for your patience...
bests,
martin
30 Aug
30 Aug
8:11 p.m.
On Mon, 30 Aug 2004 21:58:32 +0200
martin rumori <lists(a)rumori.de> wrote:
hi erik,
i've got a question regarding type combinations in libsndfile:
SF_FORMAT_FLOAT | SF_ENDIAN_CPU works with SF_FORMAT_AU on any
platform, which is great. but it doesn't work with neither aiff nor
wav.
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.
i expected that it would work with one of the both
formats,
depending on the host endianess.
SF_ENDIAN_CPU really only makes sense when the file format allows
bot endian-nesses.
some other questions regarding string data:
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?
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.
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
or the comment of the file without copying it? i guess there is a
special reason for that...
As above.
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"What lawyers call 'intellectual property' is -- as every Latin student
knows -- no more than theft from the public domain."
-- Andy Mueller-Maguhn, newly elected ICANN board member for Europe.
31 Aug
31 Aug
8:37 a.m.
On Tue, Aug 31, 2004 at 07:54:58AM +1000, Erik de Castro Lopo wrote:
yes, sorry.
i see. maybe you'd had to move the data back in order to create space
for the comment. not worth the work, agreed.
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? 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. 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
9:50 a.m.
On Mon, 30 Aug 2004 22:30:41 -0600
martin rumori <lists(a)rumori.de> wrote:
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?
For sf_format_check() to return TRUE, you MUST also set the sample
rate, channel count and number of channels.
<snip>
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.
Yes, and that should be possible. What is not possible is
openning the file RDWR and modifying the string data in the
header.
what do you
think about letting sf_set_string() fail in any other mode than
SFM_WRITE,
Yes, thats sound pretty sensible.
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?
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo nospam(a)mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"Linux is produced to be used, whereas the others are produced
to be sold" -- Bobby D. Bryant
11:55 a.m.
On Tue, Aug 31, 2004 at 09:33:44PM +1000, Erik de Castro Lopo wrote:
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.
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
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. 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?
7185
days inactive
7186
days old
linux-audio-dev@lists.linuxaudio.org
4 comments
2 participants
participants (2)
-
Erik de Castro Lopo -
martin rumori