Re: Reading sections of MP3/WMA files
- From: "Alessandro Angeli [MVP::DS/MF]" <nobody@xxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Mar 2006 15:29:38 +0100
Sam Brown wrote:
Not _quite_ what I meant. ;) I meant that I can't be
the first person to want to try this, amd that the
chances are someone would already have come up with a
solution.
As far as the WM-related groups I follow, I don't remember
anyone ever asking this.
Like I said, what puzzles me is that the WMSDK doesn't
tell you exactly where the discontiguous data it gives
you starts. If it knows enough to know that the time you
requested is inside the block it gives you the start of,
it must know what the position of the start of that block
is, surely? But it doesn't pass that info back in the
sample time. You're right, ASF probably wouldn't be able
to do this - but it could at least provide the
functionality when it _is_ possible.
If you read compressed data, the first GetNextSample() after
a SetRange() will always return a clean point which, for
audio streams, is the boundary of an audio frame. The media
type will tell you the block align of the stream and a block
contains an integral number of frames so, if you count the
bytes you read, you can know where each block starts and a
block boundary is also a frame boundary.
The above of course assumes the muxer followed the "rules"
and the WMF muxer does by default.
If you read uncompressed data, there is no relation between
the samples you read and the compressed frames: this is not
a limitation of the WMF readers, but it is so with any kind
of format unless you know the specifics of the audio stream
format.
Sorry, you're right, I'm talking rubbish here - each MP3
block may be 522 bytes, but it decompresses to a varible
amount. There may be a way of calculating the length of
a block when decompressed without actually decompressing
it all however, which would enable you to do some form of
fast skipping - I've not looked that hard though!
You may want to take a look at my sample MP3 parser to know
how to scan an MP3 stream and get the frame size:
http://groups.google.com/group/microsoft.public.win32.programmer.directx.audio/msg/096cd764c7011fb0
WMF uses the FhG ACM decoder to decompress MP3:
http://groups.google.com/group/microsoft.public.win32.programmer.directx.audio/msg/096cd764c7011fb0
An MP3 frame always has the same duration, regarding of its
size (which depends on the current bitrate), so it always
produces the same number of PCM samples (if the sample rate
and channel count doesn't change in mid-stream, which is not
really supported by the MP3 decoders so it should never
happen).
To be honest, I've started looking at ways of speeding up
the force decode of the entire file rather than randomly
seeking into the compressed files. That's really my
sticking point, and I can see a couple of ways around it
for my app, or at least coping with the 10 seconds or so
a decode to memory takes.
You can also parse the ASF yourself and decode the WMA
stream:
http://www.microsoft.com/asf
The WMA decoder is a DMO, so you can look at the DirectShow
SDK for generic DMO documentation and the WM Audio Video
Codec Interfaces SDK for WMA specific info (either the old
stand-alone SDK or the newer copy integrated in the
WindowsMediaFormat SDK 9.5).
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// a dot angeli at psynet dot net
.
- References:
- Re: Reading sections of MP3/WMA files
- From: Sam Brown
- Re: Reading sections of MP3/WMA files
- From: Alessandro Angeli [MVP::DS/MF]
- Re: Reading sections of MP3/WMA files
- From: Sam Brown
- Re: Reading sections of MP3/WMA files
- Prev by Date: Re: Reading sections of MP3/WMA files
- Next by Date: Dexter 1.0 Type Library
- Previous by thread: Re: Reading sections of MP3/WMA files
- Next by thread: wma9 Decoded Samples/frame
- Index(es):
Relevant Pages
|
Loading