12 Oct
2010
12 Oct
'10
10:49 a.m.
Hi all,
If anyone has access to any commercial software that includes
support for writing the RF64 file format, I'd appreciate it if
you send me (direct please, not to the list) a small file (ie
less than 100k) with information about the program that generated
it.
For those interested, I'm trying to get the libsndfile RF64
implementation correct in spite of the RF64 specification
being somewhat flawed [0].
Cheers,
Erik
[0] http://www.mega-nerd.com/erikd/Blog/CodeHacking/libsndfile/rf64_specs.html
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
12 Oct
12 Oct
10:02 p.m.
On Tue, Oct 12, 2010 at 09:49:43PM +1100, Erik de Castro Lopo wrote:
If anyone has access to any commercial software that
includes
support for writing the RF64 file format, I'd appreciate it if
you send me (direct please, not to the list) a small file (ie
less than 100k) with information about the program that generated
it.
Can't help with this. If you want to sort out the issues mentioned
on your web site maybe the best course would be to try and get in
contact with Davidsystems <http://www.davidsystems.com/en/top/contact/>
who must be one of the biggest commercial users of RF64, or with the
EBU (good luck with the latter).
I'm not really in love with RF64. For my own multichannel use I've
standardized on CAF - clean format, no 4GB problems, and all apps
using your library can read it. Having the option to add additional
chunks would be nice.
Ciao,
--
FA
There are three of them, and Alleline.
14 Oct
14 Oct
4:56 a.m.
fons(a)kokkinizita.net wrote:
I'm not really in love with RF64. For my own
multichannel use I've
standardized on CAF - clean format, no 4GB problems, and all apps
using your library can read it.
Thats an interesting choice.
The main thing with CAF is that it is by default a format optimised
for big endian systems (it was developed on PowerPC). All the chunk
length fields are stored big endian and by default things like 16
bit PCM data is stored big endian.
The libsndfile CAF implementation leaves the CAF defaults as they are
but allows you to specify that the audio data be stored little endian
or with the same endian-ness as the CPU. This is done by specifying
the format to be either:
SF_FORMAT_CAF | SF_FORMAT_PCM_16 | SF_ENDIAN_LITTLE
or
SF_FORMAT_CAF | SF_FORMAT_PCM_16 | SF_ENDIAN_CPU
If you are on a little endian CPU and using sf_read_short() to read
data, reading file data of the same endian-ness as the CPU will be
significatly faster than reading data that needs to be byte swapped.
Similarly for SF_FORMAT_FLOAT being read using sf_read_float().
Just letting you know.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
6:55 a.m.
On 10/14/10 06:56, Erik de Castro Lopo wrote:
fons(a)kokkinizita.net wrote:
It's a logical choice given the fact that there are not too many proper
formats for big blobs. I came to the same conclusion a few years ago and
used it ever since.
Funny that some of Apple's own programs didn't seem to support CAF with
all it's features. I remember one time giving a ~70GB recording to an
external studio for mixing and Logic couldn't open a 32 tracks float
format CAF. Luckily they had Audacity installed and extracted all tracks
manually - which took them 2h of paid studio time.. ..a bill I would
really like to send to Apple.
Flo
--
Machines can do the work, so people have time to think.
public key DA43FEF4 x-hkp://wwwkeys.eu.pgp.net
I'm not really in love with RF64. For my own
multichannel use I've
standardized on CAF - clean format, no 4GB problems, and all apps
using your library can read it.
Thats an interesting choice.
8:14 a.m.
Florian Faber wrote:
On 10/14/10 06:56, Erik de Castro Lopo wrote:
Personally I think W64 is the obvious choice for > 4Gig files on
little endian CPUs.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
fons(a)kokkinizita.net wrote:
It's a logical choice given the fact that there are not too many proper
formats for big blobs. I came to the same conclusion a few years ago and
used it ever since. I'm not really in love with RF64. For my own
multichannel use I've
standardized on CAF - clean format, no 4GB problems, and all apps
using your library can read it.
Thats an interesting choice.
12:14 p.m.
On Thu, Oct 14, 2010 at 03:56:36PM +1100, Erik de Castro Lopo wrote:
fons(a)kokkinizita.net wrote:
I'm well aware of this. For the headers the byte-swapping overhead is
really without consequence, the format allows PCM data to be written
with either endianness, and libsndfile makes this possible in the way
you describe. So all is well !
Another feature I like is that provided the headers are flushed to
disk and the data length set to -1 you get a valid file even if
it is was not closed cleanly, e.g. as a result of a power failure
or software crash. Does libsndfile do the right things to support
this ?
Ciao,
--
FA
There are three of them, and Alleline.
I'm not really in love with RF64. For my own
multichannel use I've
standardized on CAF - clean format, no 4GB problems, and all apps
using your library can read it.
Thats an interesting choice.
The main thing with CAF is that it is by default a format optimised
for big endian systems (it was developed on PowerPC). All the chunk
length fields are stored big endian and by default things like 16
bit PCM data is stored big endian.
...
10:47 p.m.
fons(a)kokkinizita.net wrote:
I'm well aware of this.
Good.
For the headers the byte-swapping overhead is
really without consequence,
Thats why I didn't mention it :-).
Another feature I like is that provided the headers
are flushed to
disk and the data length set to -1 you get a valid file even if
it is was not closed cleanly, e.g. as a result of a power failure
or software crash. Does libsndfile do the right things to support
this ?
By default, it doesn't do the right thing if the file is not properly
closed, but it is possible to force update of the header using:
http://www.mega-nerd.com/libsndfile/command.html#SFC_UPDATE_HEADER_NOW
http://www.mega-nerd.com/libsndfile/command.html#SFC_SET_UPDATE_HEADER_AUTO
The second of these updates the header at the end of each write. As
long as you are doing large writes, the overhead should be negligible.
I'll also look into doing what you suggest, writing the maximum
value for the data field length when the file is initially opened.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
11:14 p.m.
On Fri, Oct 15, 2010 at 09:47:33AM +1100, Erik de Castro Lopo wrote:
I'll also look into doing what you suggest,
writing the maximum
value for the data field length when the file is initially opened.
That is the recommended way for CAF. A lenght of -1 means
'up to end of file', and CAD readers are supposed to understand
this. So you should _not_ rewrite the header at all, until the
file is closed.
Ciao,
--
FA
There are three of them, and Alleline.
12 Oct
12 Oct
10:11 p.m.
New subject: RF64 file format and commercial software - again
On Tue, Oct 12, 2010 at 09:49:43PM +1100, Erik de Castro Lopo wrote:
If anyone has access to any commercial software that
includes
support for writing the RF64 file format, I'd appreciate it if
you send me (direct please, not to the list) a small file (ie
less than 100k) with information about the program that generated
it.
This may be useful if you have a windoze machine:
<http://www.davidsystems.com/en/news/news-detail/period/1209592800/2678399/1/article/31/david-systems-offers-rf64-generator-for-free/>
Ciao,
--
FA
There are three of them, and Alleline.
13 Oct
13 Oct
6:48 a.m.
New subject: RF64 file format and commercial software - again
Quoting fons(a)kokkinizita.net:
On Tue, Oct 12, 2010 at 09:49:43PM +1100, Erik de
Castro Lopo wrote:
Or have WINE installed (it even worked with the 0.9.20 version I've
got installed). I had it make a 4.1GB file which sndfile-info
identified as :
Version : libsndfile-1.0.20
========================================
File : /4GBwav/Stereo4Gb.wav
Length : 4295837820
RF64
WAVE
ds64 : 32
Riff size : 4295837812
Data size : 4295837712
Frames : 1073959428
Table len : 0
fmt : 40
Format : 0xFFFE => WAVE_FORMAT_EXTENSIBLE
Channels : 2
Sample Rate : 44100
Block Align : 4
Bit Width : 16
Bytes/sec : 176400
Valid Bits : 16
Channel Mask : 0x3
Subformat
esf_field1 : 0x1
esf_field2 : 0x0
esf_field3 : 0x10
esf_field4 : 0x80 0x0 0x0 0xAA 0x0 0x38 0x9B 0x71
format : pcm
data : FFFFFFFF
----------------------------------------
Sample Rate : 44100
Frames : 1073959428
Channels : 2
Format : 0x00220002
Sections : 1
Seekable : TRUE
Duration : 06:45:52.821
Strangely enough libsndfile-1.0.23 borks on the file:
Error : Not able to open input file /4GBwav/Stereo4Gb.wav.
File : /4GBwav/Stereo4Gb.wav
Length : 4295837820
RF64
WAVE
ds64 : 32
Riff size : 4295837812
Data size : 4295837712
Frames : 1073959428
Table length : 0
*** Unknown chunk marker (0x0) at position 0x34. Exiting parser.
Error in WAV file. No 'data' chunk marker.
- Peder
If anyone has access to any commercial software
that includes
support for writing the RF64 file format, I'd appreciate it if
you send me (direct please, not to the list) a small file (ie
less than 100k) with information about the program that generated
it.
This may be useful if you have a windoze machine:
<http://www.davidsystems.com/en/news/news-detail/period/1209592800/2678399/1/article/31/david-systems-offers-rf64-generator-for-free/>
7:10 a.m.
New subject: RF64 file format and commercial software - again
Quoting Peder Hedlund <peder(a)musikhuset.org>rg>:
Strangely enough libsndfile-1.0.23 borks on the file:
Error : Not able to open input file /4GBwav/Stereo4Gb.wav.
File : /4GBwav/Stereo4Gb.wav
Length : 4295837820
RF64
WAVE
ds64 : 32
Riff size : 4295837812
Data size : 4295837712
Frames : 1073959428
Table length : 0
*** Unknown chunk marker (0x0) at position 0x34. Exiting parser.
Error in WAV file. No 'data' chunk marker.
FYI it stopped working in 1.0.21. 20's OK, 21's not.
- Peder
8:01 a.m.
New subject: RF64 file format and commercial software - again
Peder Hedlund wrote:
Quoting fons(a)kokkinizita.net:
Yep, ran that under Wine. Interestingly the program agrees with my
interpretation of the flawed RF64 spec.
<http://www.davidsystems.com/en/news/news-detail/period/1209592800/2678399/1/article/31/david-systems-offers-rf64-generator-for-free/>
Or have WINE installed (it even worked with the 0.9.20 version I've
got installed). Strangely enough libsndfile-1.0.23 borks on the file:
Error : Not able to open input file /4GBwav/Stereo4Gb.wav.
File : /4GBwav/Stereo4Gb.wav
Length : 4295837820
RF64
WAVE
ds64 : 32
Riff size : 4295837812
Data size : 4295837712
Frames : 1073959428
Table length : 0
*** Unknown chunk marker (0x0) at position 0x34. Exiting parser.
Fixed that. Working correcty now.
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
5306
days inactive
5308
days old
linux-audio-user@lists.linuxaudio.org
11 comments
4 participants
participants (4)
-
Erik de Castro Lopo -
Florian Faber -
fons＠kokkinizita.net -
Peder Hedlund