Help - Search - Members - Calendar
Full Version: DShow and mp3 with long silence lead-in problem
Hydrogenaudio Forums > Hydrogenaudio Forum > General Audio
damien_1
Hi all,

I'm using DirectShow to play mp3 files using the default graph builder on my XP system:
...
myGraphBuilder->RenderFile (filename, NULL);
...
myMediaControl->Run();

This works fine for almost all mp3 files I have tried (hundreds), except for a handful of mp3s, which all came from the same source. What happens is that everything initializes without error and the file appears to play, but without any sound. When I do a:

myMediaSeeking->GetPositions(...);

it returns correct positions based on how long the file's been playing – but no sound.

If I seek to a random position and play, then I DO hear the audio just fine. It's just when it's played from the start position and allowed to play that I don't get any sound.

I've examined the waveforms of the files in a sound editor and the only thing that I can see that's different about these files is that they have a long lead-in of total silence – from about 300 ms to over a 1 sec. I've found that I can make the files play correctly, with audio, if I seek to not less than about 200ms before the start of the actual audible sound samples.

Other players like WMP et al, all seem to be able to play these files without problem.

Does anyone know what I need to do in DShow to make these files play correctly from the start? Is there perhaps some buffer size that needs to be made bigger or something else? Any help would be greatly appreciated.

Thanks.
j7n
If they're 320 kBit/s files you need to upgrade the MPEG Layer-3 decoder to v1.9, or perhaps install a completely alternative decoder.

The PsyTEL AAC developers recently were able to convince LAME devs to restrict the bit reservoir, or something like that, to make 320 kBit encodes compatible with the original decoder.

It could be that during the silent period a sufficiently large bit reservoir did build up, and the problem would not become apparent if audio started immediately. Quality would be less for the first frames of course (not that it matters at 320 kBit).
damien_1
Yes, they were 320 kbit/s CBR. I did also resample them to 256, but also without success. However, 192 CBR seemed to work ok.

QUOTE ("j7n")
...you need to upgrade the MPEG Layer-3 decoder to v1.9, or perhaps install a completely alternative decoder.

Thanks for the tip, however, I would like to solve this problem with my current setup, if at all possible. As I noted before, other media players on my system don't have this problem (WMP, Winamp, VLC), though Media Player Classic does have the problem.

Any idea why the other players would play ok? Is there anything I can try within DShow? I take it that WMP also uses DS...
j7n
I believe the big Windows Media Player uses different DLLs for decoding ("DMO" something). I don't use or have this player. If you execute mplayer2.exe, the old program that was previously known as "media player", the same problem should surface.

Winamp, Foobar2000, XMPLAY, VLC use they're own decoders and have nothing to do with DirectShow.

In case you're worrying about viruses. The AX file I posted is just compressed with UPX, for no particular reason, and is not infected.

http://www.hydrogenaudio.org/forums/index....showtopic=40308
damien_1
Thanks, I'll give it a try.
Martel
Try installing K-lite codec pack, it should solve your issues. You can then configure what formats are handled by what decoder and pick up the best one (Start-programs-K_lite codec pack-configuration-ffdshow audio decoder).
DirectShow is very convenient to use if you want a simple, yet powerful application (since you can automatically decode whatever there is a windows codec for). It also allows you to outsource all the configuration interfaces to ffdshow etc.
menno
If you really want/need to use this filter (we do when there is no mp3 playback license in Nero), there are a couple of ways to solve this. Basically you need to make sure those first few frames do not get send to the filter. You could do this by adding some dshow filter in front of the decoder that detects these frames, or maybe test the file separately and then seek to a point after the frames.
Note that these errors can also occur anywhere else in the file when there are silent parts, but this is much less common than at the start.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2009 Invision Power Services, Inc.