UA in WavPack

26 views
Skip to first unread message

e deleflie

unread,
Sep 29, 2009, 8:16:51 AM9/29/09
to ambis...@googlegroups.com
There are several ways that UA could be implemented in WavPack.

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

e deleflie

unread,
Oct 22, 2009, 10:24:26 PM10/22/09
to ambis...@googlegroups.com
docs on how to make a *.ua file are here:

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

Oliver Thuns

unread,
Oct 23, 2009, 4:07:18 AM10/23/09
to ambis...@googlegroups.com
If you are using APE-Tags for the Ambisonics metadata, it really
doesn't matter which file format you are using, as long as it supports
enough channels and custom tags. This is applicable to Ogg/Vorbis,
Flac (up to 2H1V) and Ogg/Flac (for lossless streaming), maybe AAC
(but we don't want to use non-open-source and patented stuff, do we?),
anything in a MKA/MKV container and future codecs / audio file
formats.

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). this said, after i'm looking back to
what we have achived in the last year and that i mentioned the
possibility of using this hack over a year ago in the ambisonics.ch
list, i'm not sure that we will see a technical correct solution that
will be widely used anytime soon.

conclusion:
- your proposal is a hack / workaround
- i feel it's okay to use a workaround, if there are no solutions that
can be used today
- it's not restricted to wavpack

though i wouldn't call it a standard.

e deleflie

unread,
Oct 23, 2009, 5:51:20 AM10/23/09
to ambis...@googlegroups.com
> If you are using APE-Tags for the Ambisonics metadata, it really
> doesn't matter which file format you are using, as long as it supports
> enough channels and custom tags. This is applicable to Ogg/Vorbis,
> Flac (up to 2H1V) and Ogg/Flac (for lossless streaming), maybe AAC
> (but we don't want to use non-open-source and patented stuff, do we?),
> anything in a MKA/MKV container and future codecs / audio file
> formats.

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

Reply all
Reply to author
Forward
0 new messages