weba audio format
Mark Constable
standalone "webm" audio files be in ogg/vorbis format?
Matthew Heaney
> Is there really a *.weba (audio/weba) format
The MIME type is "audio/webm".
I believe the term "weba" and/or file extension ".weba" has been
trademarked by a different company for an unrelated product, so no
agreement has been reached yet about what file extension to use for
audio-only webm files. For now, you can just use ".webm". (This only
matters if you're playing from a local file, of course.)
> or should
> standalone "webm" audio files be in ogg/vorbis format?
While the Vorbis audio codec is part of the WebM project, the Ogg
container format is not. The WebM container (based on Matroska) is
more storage efficient than Ogg, and plays in more browsers.
(If you're using Windows, note that the DirectShow filters for WebM
now include support for converting Ogg/Vorbis files to Webm.)
-Matt
Basil Mohamed Gohar
While the Vorbis audio codec is part of the WebM project, the Ogg container format is not. The WebM container (based on Matroska) is more storage efficient than Ogg, and plays in more browsers.
Matthew Heaney
<abu_hu...@hidayahonline.org> wrote:
>
> Just out of curiosity, what browser has support for WebM that does not have
> support for Ogg Vorbis?
IE9
Cristian Adam
for Ogg Vorbis / Theora in IE9. I hope to have some time in April / May to hack the
support in. Unless IE9 has whitelisted only WebM.
Cheers,
Cristian.
Basil Mohamed Gohar
antistress
only or if ogg vorbis has to be preferred
some related topics :
http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/e76771b04faf60c9/
http://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/6217a9e16cbc52ff/
Matthew Heaney
>
> Based on WebM Media Foundation codecs it shouldn't be that hard to add
> support
> for Ogg Vorbis / Theora in IE9. I hope to have some time in April / May to
> hack the
> support in. Unless IE9 has whitelisted only WebM.
Right, the MIME types "video/webm" and "audio/webm" were specially
blessed by IE9, so I don't think Ogg container rendering in IE9 will
be possible.
Matthew Heaney
But I think IE9 treats the MIME types "video/webm" and "audio/webm" as
distinguished.
Matthew Heaney
> it's not clear to me either wheither webm is a good choice for audio
> only or if ogg vorbis has to be preferred
I think Ogg was designed for unreliable connection protocols, but that
case doesn't apply to streaming over an HTTP connection. WebM is
intended as the universal WWW medium, so If you want to play Vorbis
audio in your browser, there's no reason not to use WebM as the
container (especially since that's your only option in IE9 anyway).
Also, the WebM container is more storage efficient than Ogg, so that's
yet another reason to prefer WebM.
Monty Montgomery
No, it was designed for all-or-nothing packet networks. It does
feature error/gap detection, but not concealment or correction. Ogg
and Matroska were designed with similar goal points.
> Also, the WebM container is more storage efficient than Ogg, so that's
> yet another reason to prefer WebM.
Though it's logical for Google to be pushing for the Matroska
container, this is false. Ogg is a more efficient container for
Vorbis. That said, the difference is entirely negligible in practice.
Monty
Matthew Heaney
>
> Though it's logical for Google to be pushing for the Matroska
> container, this is false. Ogg is a more efficient container for
> Vorbis.
No, this is incorrect. A WebM file that uses lacing (Xiph-style or
otherwise) for audio frames easily beats Ogg, even in the worst case
when you have one cluster element per Ogg packet.
-Matt
Monty Montgomery
Ogg adds 28 bytes per page header + [on average] 1+epsilon bytes per
Vorbis packet (typically 150-250 bytes). Assuming 64kbps audio,
that's ~186 byte packets + 1 byte for the lacing, approximately 2
pages per second (4kB page spill default), so an overhead of 99 bytes
per second or 792 bits per second for 64kbps audio (1.2%). If we
choose to use larger pages, that drops as low as 372 bits per second
overhead (.57%). That includes all the structures needed for
seekability, error detection and stream capture, as these are not
optional entities in Ogg.
Monty
Matthew Heaney
> On Thu, Mar 31, 2011 at 10:27 AM, Matthew Heaney
>
> Vorbis packet (typically 150-250 bytes).
Right, but a WebM file that uses lacing for audio frames requires
fewer than 28 bytes per Vorbis packet.
Monty Montgomery
> fewer than 28 bytes per Vorbis packet.
You are confusing Ogg packets and Ogg pages. For a long time FFMPEG
was making the same mistake (putting one Vorbis packet per Ogg page).
A properly constructed Ogg's overhead is slightly more than one byte
per Vorbis packet.
Monty
Matthew Heaney
>
> You are confusing Ogg packets and Ogg pages. For a long time FFMPEG
> was making the same mistake (putting one Vorbis packet per Ogg page).
>
> A properly constructed Ogg's overhead is slightly more than one byte
> per Vorbis packet.
My understanding is that an Ogg page can store up to a maximum of 255
Vorbis packets. Are you claiming otherwise?
Gregory Maxwell
I suspect you've been using some busted ogg mux that only places one
packet per page, or in other words old ffmpeg. Current ffmpeg tightly
muxes.
E.g.
https://people.xiph.org/~greg/comp48s-ffmpeg.ogg
912435 bytes
https://people.xiph.org/~greg/comp48s.weba
926583 bytes
(remuxed with mkvmerge)
Of course— these are very small differences. It's only worth replying
to you because you keep repeating it as if it were actually
significant in this case. Of course, it shouldn't be that different:
MKV has the xiph lacing from ogg.
Basil Mohamed Gohar
The commands I used were the following:
ffmpeg -y -i united-masajid-of-columbus.flac -acodec libvorbis -aq 1 -f ogg united-masajid-of-columbus-container-test.oga
ffmpeg -y -i united-masajid-of-columbus.flac -acodec libvorbis -aq 1 -f matroska united-masajid-of-columbus-container-test.mka
ffmpeg -y -i united-masajid-of-columbus.flac -acodec libvorbis -aq 1 -f webm united-masajid-of-columbus-container-test.weba
The sizes I got are the following:
42594544 Mar 31 10:56 united-masajid-of-columbus-container-test.oga (muxing overhead 0.650924%)
44049171 Mar 31 10:59 united-masajid-of-columbus-container-test.mka (muxing overhead 4.088208%)
44049100 Mar 31 11:02 united-masajid-of-columbus-container-test.weba (muxing overhead 4.088040%)
Encoded Vorbis data bitrate ended-up being: 74.1kbits/s
The file in question is 4754.27 seconds in length.
I have *no* idea what methods ffmpeg uses for WebM muxing, including whether-or-not it uses any of the optimization that WebM has for such a case, as Matthew has mentioned above.
(All numbers, aside from final file size, are as reported by ffmpeg.)
Matthew Heaney
>
> I suspect you've been using some busted ogg mux that only places one
> packet per page, or in other words old ffmpeg. Current ffmpeg tightly
> muxes.
I understand that an Ogg page comprises several Vorbis packets (up to
a maximum of 255), and I didn't mean to suggest otherwise. My claim
that "WebM easily beats Ogg" stands, however, because you can store as
many Vorbis audio frames on a Webm audio block (that uses lacing) as
you can Vorbis audio packets on an Ogg page. WebM is more efficient
because the amortized cost of cluster element overhead approaches 0 as
more audio blocks are put on the same cluster.
> Of course— these are very small differences. It's only worth replying
> to you because you keep repeating it as if it were actually
> significant in this case. Of course, it shouldn't be that different:
> MKV has the xiph lacing from ogg.
Right, and the reason that WebM is more storage efficient than Ogg has
everything to do with Ogg page overhead. The number of Vorbis packets
on an Ogg page is an orthogonal issue, because the number of Vorbis
packets is the same in both cases.
-Matt
Matthew Heaney
> 912435 bytes
>
> https://people.xiph.org/~greg/comp48s.weba
> 926583 bytes
When I use the WebM DirectShow filters to mux convert from Ogg to Webm I get:
comp48s.webm
912111 bytes
Which beats Ogg, as expected.
-Matt
Monty Montgomery
<matthew...@google.com> wrote:
> My claim
> that "WebM easily beats Ogg" stands, however, because you can store as
> many Vorbis audio frames on a Webm audio block (that uses lacing) as
> you can Vorbis audio packets on an Ogg page. WebM is more efficient
> because the amortized cost of cluster element overhead approaches 0 as
> more audio blocks are put on the same cluster.
Just as Ogg page overhead approaches zero. The overhead is dominated
by the lacing, which is the same in both. However, to beat Ogg by
amortizing the cluster overhead with arbitrarily large clusters as
you're suggesting, you also eliminate the ability to seek in the file.
That is not a realistic usage.
Monty
Gregory Maxwell
<matthew...@google.com> wrote:
> On Thu, Mar 31, 2011 at 11:10 AM, Gregory Maxwell <gmax...@gmail.com> wrote:
>> https://people.xiph.org/~greg/comp48s-ffmpeg.ogg
>> 912435 bytes
>> https://people.xiph.org/~greg/comp48s.weba
>> 926583 bytes
> When I use the WebM DirectShow filters to mux convert from Ogg to Webm I get
> comp48s.webm
> 912111 bytes
Congrats, you've saved 28.6 bits per second!
Obviously worth a dozen snarky mailing list messages and breaking
compatibility with (hundreds of?) millions of older mediaplayer
devices!
More seriously, if your DirectShow filters aren't producing hideous
output it would be really helpful if you'd prod the folks working on
mkclean to improve, since I'm not able to get that small a file using
mkvmerge or mkvclean.
Matthew Heaney
>
> Just as Ogg page overhead approaches zero.
> The overhead is dominated
> by the lacing, which is the same in both.
You are conflating WebM audio blocks and WebM cluster elements. The
lacing overhead only applies to audio blocks (and we appear to be in
agreement that it's the same in both cases), but WebM allows you to
put multiple audio blocks on the same cluster. Even in the worst
case, when there is one audio block (containing, say, 255 laced frames
of audio), WebM still beats Ogg, because the cluster overhead is less
then 28 bytes.
> However, to beat Ogg by
> amortizing the cluster overhead with arbitrarily large clusters as
> you're suggesting, you also eliminate the ability to seek in the file.
> That is not a realistic usage.
I don't understand this argument, because a canonical Ogg/Vorbis file
does not have a seek index, so seeking isn't even possible, but let's
put that argument aside. For the WebM file, use a typical cluster
size, such as 5s, and my claim that WebM is more store efficient than
Ogg still stands.
-Matt
Matthew Heaney
>
> Obviously worth a dozen snarky mailing list messages and breaking
> compatibility with (hundreds of?) millions of older mediaplayer
> devices!
I don't understand what the compatibility issue is, since WebM is
supported by all the major browsers with the exception of Safari.
> More seriously, if your DirectShow filters aren't producing hideous
> output it would be really helpful if you'd prod the folks working on
> mkclean to improve, since I'm not able to get that small a file using
> mkvmerge or mkvclean.
I'll have to analyze what they're doing. Either they're putting in
some extra elements, or the elements aren't being formatted optimally.
-Matt
Monty Montgomery
>> amortizing the cluster overhead with arbitrarily large clusters as
>> you're suggesting, you also eliminate the ability to seek in the file.
>> That is not a realistic usage.
>
> I don't understand this argument
Matroska/WebM absolute timing information is by cluster as is seek
information. If your clusters are 5s, your seeking resolution is only
within 5s. To amortize cluster overhead to zero, you have to make
bigger and bigger clusters, approaching the logical extreme of one
huge cluster. In such a case, you can only decode from the beginning
of a file. This is absurd, yes, but that's what's necessary in your
argument to 'easily beat' Ogg.
> because a canonical Ogg/Vorbis file
> does not have a seek index, so seeking isn't even possible
To avoid sounding snarky, I'll be blunt: This is a head-up-ass
statement. 'I don't like the seeking system' is very different from
'seeking isn't even possible'. I'm happy to grant you the former.
FTR you can, if you want, put an index in an Ogg file. It's simply
not required, just like it isn't required in Matroska, which then
falls back to seeking exactly the same way Ogg does. I realize that
WebM makes the seek index mandatory and that the mandatory index makes
perfect sense in this use case.
> For the WebM file, use a typical cluster
> size, such as 5s, and my claim that WebM is more store efficient than
> Ogg still stands.
OK, 5s cluster size, so to be fair, 5s Ogg page size.
64 kbps Vorbis is 186 bytes per Vorbis packet. Both Ogg and Matroska
are going to use Xiph lacing for this because it's most efficient in
this case.
That's 43 packets per second, so 215 packets for 5s. That's 28+215
bytes overhead in the Ogg muxing, or 243 bytes for 5 second, or 389
bits overhead per second for .6% overhead.
(I realize this is unrelated to the raw bit overhead argument, but
that 389 bits per second gets you error, capture, gap and truncation
detection, because, again, those aren't optional in Ogg and I don't
recall if WebM allows that now. It didn't in the early drafts. I
agree that checksums are of only marginal use in video, but they're
essential in audio. Audio bit errors can and do damage equipment and
hearing).
I'll let you do the math for WebM since it's true I haven't looked at
the draft spec since summer last year. I'm well versed in Matroska
itself, but I'm not sure I've kept up with the WebM restrictions.
Monty
Monty Montgomery
> not required, just like it isn't required in Matroska, which then
> falls back to seeking exactly the same way Ogg does. I realize that
> WebM makes the seek index mandatory and that the mandatory index makes
> perfect sense in this use case.
Oh, it is worth pointing out that a mandatory index makes live
streaming impossible without resorting to something like DASH, and
that comes with a sizeable latency penalty (eg, useless for
teleconference, etc). Again, that wasn't part of this specific
numbers argument, but it's also not fair to make it sound like an
index is an obvious 'always-on' no-brainer that comes without any
liabilities, and we were remiss for not mandating it from the start.
Monty
Måns Rullgård
SMC
> On Thu, Mar 31, 2011 at 11:35 AM, Gregory Maxwell <gmax...@gmail.com> wrote:
>> Obviously worth a dozen snarky mailing list messages and breaking
>> compatibility with (hundreds of?) millions of older mediaplayer
>> devices!
> I don't understand what the compatibility issue is, since WebM is
> supported by all the major browsers with the exception of Safari.
browsers.
There is quite a lot of portable media players that have support for Ogg
Vorbis audio, but none(as far as I know) that suport ".weba" currently.
(this may not be true of Android "gingerbread" which supposedly has webm
support, and therefore MAY support audio-only "weba" files as well)
There is also a lot of software that has built-in support for Ogg Vorbis
(dedicated media players, and video game software using Ogg Vorbis for sound
effects, music, etc.) that will/would need to be rewritten to add support for
Matroska containers for vorbis audio.
(Has anyone tested audio-only "weba" in any of the browsers out now? I'd be
curious to know if any work, and I've not yet run across an audio-only "webm"
file).
Unlike Ogg Theora which webm replaces handily (due to Theora - in my opinion
- getting off to far too slow of a start to catch on in time), Ogg Vorbis
actually has pretty substantial market penetration for an under-marketed
non-proprietary format.
(I'm not a real "developer" so I've got no way of judging the technical
merits of the two container formats, but as someone who likes to think of
himself as an "advanced user", I'm not seeing a benefit to repackaging my Ogg
Vorbis audio into a Matroska container just because I might be able to play
them in IE9 if I do...)
Matthew Heaney
>
> That's 43 packets per second, so 215 packets for 5s. That's 28+215
> bytes overhead in the Ogg muxing, or 243 bytes for 5 second, or 389
> bits overhead per second for .6% overhead.
Right, but it's that 28 bytes of Ogg page overhead that you must
compare to the WebM alternative.
Thanks for the Ogg info -- it's been a useful discussion.
Regards,
Matt
Monty Montgomery
<matthew...@google.com> wrote:
> On Thu, Mar 31, 2011 at 12:41 PM, Monty Montgomery <xiph...@gmail.com> wrote:
>>
>> That's 43 packets per second, so 215 packets for 5s. That's 28+215
>> bytes overhead in the Ogg muxing, or 243 bytes for 5 second, or 389
>> bits overhead per second for .6% overhead.
>
> Right, but it's that 28 bytes of Ogg page overhead that you must
> compare to the WebM alternative.
I did compare it. It's broken out above. That 389 bits/second number
is total overhead, everything, including the 28 byte page overhead.
Cheers,
Monty
Steve Lhomme
<matthew...@google.com> wrote:
> On Thu, Mar 31, 2011 at 11:10 AM, Gregory Maxwell <gmax...@gmail.com> wrote:
>>
>> https://people.xiph.org/~greg/comp48s-ffmpeg.ogg
>> 912435 bytes
>>
>> https://people.xiph.org/~greg/comp48s.weba
>> 926583 bytes
>
> When I use the WebM DirectShow filters to mux convert from Ogg to Webm I get:
>
> comp48s.webm
> 912111 bytes
Can you put the file online ? I can only reach 921805 bytes with
"mkclean --remux --unsafe". It doesn't "relace" the frames though. So
it's mostly 8 per Blocks as it is the max in mkvmerge and likely
FFMPEG. It would be possible to put one Block per Cluster and one
Cluster every 10s to reach low overhead. But at the price of very bad
seeking. mkclean makes a Cluster every 1 second and add the Cues at
the front (5 kb).
--
Steve Lhomme
Matroska association Chairman
Monty Montgomery
>>> 912435 bytes
>>>
>>> https://people.xiph.org/~greg/comp48s.weba
>>> 926583 bytes
>>
>> When I use the WebM DirectShow filters to mux convert from Ogg to Webm I get:
>>
>> comp48s.webm
>> 912111 bytes
Out of curiosity, is that using compressed headers in the webm file?
Monty
Steve Lhomme
>> For the WebM file, use a typical cluster
>> size, such as 5s, and my claim that WebM is more store efficient than
>> Ogg still stands.
>
> OK, 5s cluster size, so to be fair, 5s Ogg page size.
>
> 64 kbps Vorbis is 186 bytes per Vorbis packet. Both Ogg and Matroska
> are going to use Xiph lacing for this because it's most efficient in
> this case.
Too bad mkvinfo doesn't show the kind of lacing used. But usually EBML
lacing is more efficient than Xiph lacing for just about anything.
Good Matroska muxers pick the best one before writing a block (that's
what libmatroska does transparently). Fixed lacing is very good for
CBR content too.
> (I realize this is unrelated to the raw bit overhead argument, but
> that 389 bits per second gets you error, capture, gap and truncation
> detection, because, again, those aren't optional in Ogg and I don't
> recall if WebM allows that now. It didn't in the early drafts. I
> agree that checksums are of only marginal use in video, but they're
> essential in audio. Audio bit errors can and do damage equipment and
> hearing).
CRC32 is supported by WebM. It can be placed at any level inside
Matroska. (mkclean puts some at every key level, unless you put
--unsafe).
Steve Lhomme
1/ it is not supported by WebM
2/ it has no effect on Vorbis and VP8 anyway (so not needed in WebM anyway)
Monty Montgomery
> lacing is more efficient than Xiph lacing for just about anything.
Yes, but this is the case where the EBML lacing is straddling the
one/two byte boundary and the Xiph lacing is not. If Matroska had a
more efficient lacing for small packets at its disposal (and was using
it) it would be fair for it to use that. As it is, in this specific
case, the Xiph lacing is always going to win. The EBML lacing will
solidly pull ahead up over 190kbps audio or so.
> CRC32 is supported by WebM. It can be placed at any level inside
> Matroska. (mkclean puts some at every key level, unless you put
> --unsafe).
Good. I think CRC32 was not allowed in at least one earlier draft,
glad to see that's been reconsidered (if I'm wrong, I'm happy to be
wrong). And it absolutely should be used for audio data.
Monty
Monty Montgomery
> 2/ it has no effect on Vorbis and VP8 anyway (so not needed in WebM anyway)
Really? Vorbis headers are very squishy. FTR, I'm referring to use
of LZW on the headers, not 'de-replicating' repeated headers.
Monty
Steve Lhomme
OK, by compressed header in Matroska that means "stripping header". A
whole Block is "compressed". One of these compression is "header
stripping", the other being zlib (other ones have been dropped). I
don't think applying zlib on Vorbis packets will have much effects
(otherwise there's a problem in Vorbis). "mkclean --optimize" will try
header stripping on audio and video codecs and pick the biggest common
header. So far in Vorbis and VP8 I've never found even 1 byte common.
(H264 usually has at least 1 byte).
Monty Montgomery
> whole Block is "compressed".
Right. I literally meant 'compressing the private headers'.
Apologies for tripping on the terminology.
> I
> don't think applying zlib on Vorbis packets will have much effects
> (otherwise there's a problem in Vorbis).
You'd get nothing on the audio packets, but the headers are not as
dense as the audio packets. gzip (and I imagine bzip2 and 7zip) all
manage to get some traction on the Vorbis initial header triad last I
checked.
Monty
Steve Lhomme
That could be investigated, because right now one of the big problem
in WebM is the size of the Vorbis init packet. It would be very to add
an extension to Matroska to have it compressed. In fact being a codec
private it would just take calling the codec "A_VORBIS2" and treating
the codec private as zlib compressed rather than raw. Adding support
in all OSS players will be very fast and easy.
Monty Montgomery
> in WebM is the size of the Vorbis init packet. It would be very to add
> an extension to Matroska to have it compressed. In fact being a codec
> private it would just take calling the codec "A_VORBIS2" and treating
> the codec private as zlib compressed rather than raw. Adding support
> in all OSS players will be very fast and easy.
In my fantasy world, we had enough warning ahead of time to just
eliminate it. Since it's too late and we're closer to Detroit than
Utopia, I decided to be content doing it differently next time (eg,
see CELT).
Ah well.
The compressed alternative is at least quicker. We can dream.
Monty
Moritz Bunkus
On Thursday 31 March 2011 22:20:14 Steve Lhomme wrote:
> That could be investigated, because right now one of the big problem
> in WebM is the size of the Vorbis init packet. It would be very to add
> an extension to Matroska to have it compressed. In fact being a codec
> private it would just take calling the codec "A_VORBIS2" and treating
> the codec private as zlib compressed rather than raw. Adding support
> in all OSS players will be very fast and easy.
Matroska (unlike WebM) supports compressing codecprivate already via the
ContentEncoding element and its children (with (ContentEncodingScope &
2) == 2). It would make much more sense to use ContentEncoding with WebM
as well (support for basic zlib compressed subtitles is already present
in many hardware players) than to invent arbitrary new codecIDs just for
this minor difference.
Not that compressing would actually gain all that much as this
discussion showed.
Regards,
Mosu
Steve Lhomme
Well, the size of the CodecPrivate for Vorbis is an important issue in
WebM. In the case of adaptive streaming you need to download the next
part of the stream right after the first one is finished. And the
extra data overhead between the 2 Clusters is as much time/bandwidth
wasted to achieve the target bandwidth. That's why a tight container
is important there and also the smallest header (+trailer) possible as
well. Unfortunately the Vorbis init is making the WebM case worse than
it should. If we can reduce it by half that would be really welcome.
Steve Lhomme
0.8.2. It doesn't do anything on WebM files as compression is not
supported. So you need to use "--doctype 2 --optimize" to have
compressed Vorbis private data (will have no effect on other codec
where the codec private is too small). In the end we save 1.3 KB out
of 4 KB (about a third of the size in general). That's about one TCP
packet so it's nice for streaming startup time, and it's very easy to
handle on the playback side. Unfortunately most players probably don't
support it yet (Haali's splitter does).
As said before it could be useful for adaptive streaming so maybe
should be considered for WebM.
Steve
Vladimir Pantelic
> I just added support for Codec Private zlib compression in mkclean
> 0.8.2. It doesn't do anything on WebM files as compression is not
> supported. So you need to use "--doctype 2 --optimize" to have
> compressed Vorbis private data (will have no effect on other codec
> where the codec private is too small). In the end we save 1.3 KB out
> of 4 KB (about a third of the size in general). That's about one TCP
> packet so it's nice for streaming startup time, and it's very easy to
> handle on the playback side. Unfortunately most players probably don't
> support it yet (Haali's splitter does).
can you make a short sample available online?
Steve Lhomme
and run "mkclean --optimize --doctype 2 <your.webm>" and you'll have
it.
> --
> You received this message because you are subscribed to the Google Groups
> "WebM Discussion" group.
> To post to this group, send email to webm-d...@webmproject.org.
> To unsubscribe from this group, send email to
> webm-discuss...@webmproject.org.
> For more options, visit this group at
> http://groups.google.com/a/webmproject.org/group/webm-discuss/?hl=en.
tunt...@gmail.com
Pada Khamis, 31 Mac 2011 2:52:05 ptg UTC+8, Mark Constable menulis:
Is there really a *.weba (audio/weba) format or should
standalone "webm" audio files be in ogg/vorbis format?
Ralph Giles
> Is there really a *.weba (audio/weba) format or should
> standalone "webm" audio files be in ogg/vorbis format?
this confuses some interfaces and .ogg is more widely supported. I
suppose the only advantage would be playback on IE with the WebM plugin
installed.
For web audio I'd recommend vorbis in .ogg, or the new Opus codec in the
ogg container '.opus'.
-r