One is to use CAF files or W64 files. Probably CAF files. This would
require 2 command line executions (or maybe 1, eventually). One to
create the CAF file, an other to compress to WavPack.
Metadata could be contained in the CAF file, or in the WavPack file,
or both (probably the best option).
An other option is that mono Wav files are used. This has 2
advantages. One is that only the WavPack command line would be used (1
step creation), the other is that many b-format files start as mono
channels anyway (and many DAWs will require mono Wav files). This
means we would be restricted to the 2GB limit, but when considered on
a per-channel level its not a big restriction. It also means that the
metadata would always be (and only be) contained in the WavPack
wrapper.
thoughts?
Etienne
http://soundofspace.com/static/make_ua_file.html
I hope to create a wrapper around the wavpack command line that does
error checking to make sure that the UA file is complicant. Coming
later.
Etienne
sure, so all of those file formats could do UA compatible files. I
have nothing against non-open-source and patented formats... other
than affordability. Price can be a good quality guarantee sometimes.
To my mind, Wavpack has 6 things going for it:
1. good quality lossless
2. free on all OS'es
3. a very supportive and cooperative developer (in David Bryant)
4. lossy mode which doesn't affect phase accuracy (apparently)
5. the lossy mode can have an accompanying 'correction' file which
will restore the file to its original lossless state
6. the forward roadmap (I believe) includes support for files larger
than the 2/4GB limit.
> the only problem i see, is that this kind of metadata stored in tags
> should never be essential for playing the file (decoding the audio
> regarding to the channel map).
You may well be right, ... I'm thinking 'bootstrap' more than 'hack'
... but whatever ... users wont hear the hack. I'm just really excited
that I will finally be able to deliver the 'producer's recommended
stereo decode'. I'm also really excited that if any developer wants to
develop software to support UA, all they need to do is write 3rd order
plugins. And if anyone wants to develop a decoder that will be able to
decode all UA files, they know exactly what they have to do. If
someone downloads a UA decoder, they'll know exactly what their
getting.
Lets hope that the other efforts to define ambisonic formats do take
off. I think we need a 'generic' format that allows defining any
combination of mixed orders... perhaps with support for various
normalisation schemes and channel orders/combos.... a true 'ambisonics
exchange' format. UA is not that ... UA is just about trying to make
it as easy as possible ... mainly by removing decisions ... trading
flexibility for simplicity, convention over configuration ... user
experience ... all that kind of stuff.
Etienne