22 May '13 - 00:57 *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
 
   Home   Help Search Login Register  
Pages: [1]
  Reply  |  Print  
Author Topic: Fast file decode  (Read 688 times)
fmcoder
Posts: 386


« on: 21 Jun '12 - 09:23 »
Reply with quoteQuote

I want to display a waveform of a file. To display it I decode the whole file using BASS_ChannelGetData and then draw it using the PCM values.
All this works, but takes about 3-5 seconds to display (for the average mp3 file).

I tried to decode a little part, then change position ahead, decode another small part and so on... But the waveform looks a little bit different if I do it this way Smiley

Is there a way to speed up the decoding process somehow? Perhaps trade quality for speed?
Logged
gnag
Posts: 160


« Reply #1 on: 21 Jun '12 - 10:18 »
Reply with quoteQuote

Hello,
my first question is, how are you collecting the PCM Values?

I think the best performance would be to get the Length (Filesize) of your Channel (MP3 File) and then use BASS_ChannelGetData with that Length as the Parameter to request the whole File at once.

Can you check how long that would take? It should be very fast.

I think the drawing Part might be a Bottleneck, if youre using C# or VB .NET and SetPixel() to draw you get a lot of overhead, there are ways to draw the Bitmap directly which is a lot faster. You can check this Article: http://www.vcskicks.com/fast-image-processing.php
Logged
fmcoder
Posts: 386


« Reply #2 on: 21 Jun '12 - 17:51 »
Reply with quoteQuote

BASS_ChannelGetData for a whole file at once still takes couple of seconds.

The drawing is not a problem, I use GDI+ and it's really fast. Also the code which reads a track is in another thread, and I measure the time it takes to decode the file.

Decoding a file is a problem... It takes too long (it's not instant Smiley)
Logged
drugoimir
Posts: 15


« Reply #3 on: 21 Jun '12 - 18:25 »
Reply with quoteQuote

Hi,

I think, anything you do, the waveform will not be as the original because, and you cannot avoid this, you loose datas.
It is the same problem when you decimate (passing from a high samplerate to a lower samplerate) a waveform: before decimation,
you have to filter out all frequencies in the original file that will not "fit" into the new samplerate, so you will loose datas and the
result will not be any longer similiar  to the original.

I don't know your application but, for what i've seen around on most commercial audio softwares, the very first time a file is loaded,
it takes some more time to be decoded because it is analyzed and a waveform peak file is generated.
In this file you could store the original waveform, decimated at a convenient rate (example you had 1 million points, you save
1000 points).
Before to save the file, you could also decide how to pick the significant points: taking one sample of the original wform out of, say, 1000,
you can decide to store the highest value among the others, so to preserve maximum peaks.
You can then use this for a quick waveform representation of the whole file.
If the user then want to zoom deeply into the waveform, you then could read the datas directly from the file, but in this case you 'll be
fast, because you will not have to decode the whole file but just a small part, that part the user want to see "enlarged".

Bye
drugo
Logged
Xire
Posts: 234


« Reply #4 on: 25 Jun '12 - 11:53 »
Reply with quoteQuote

Decoder will always return the same data, regardless of the buffer size Wink
« Last Edit: 25 Jun '12 - 12:18 by Xire » Logged
fmcoder
Posts: 386


« Reply #5 on: 25 Jun '12 - 17:58 »
Reply with quoteQuote

@drugoimir - yes caching a waveform is not a question... The question is how to decode file without consuming time? Using cache is possible, but it will still take time for first time display.

Currently it takes couple of seconds to decode 5 minute MP3, but users complaing that it's too much wait and they want instant waveform display. =)

Decoder will always return the same data, regardless of the buffer size Wink
Of course, but speed can be different. Eg if you do millions of calls to _GetData with 1 byte buffer, it will take some time to decode Smiley
Logged
gnag
Posts: 160


« Reply #6 on: 25 Jun '12 - 21:37 »
Reply with quoteQuote

@fmcoder: In theory the Disk should have about 40-60 MB/S (Normal SATA Disks) so it would be lees than 1 MB on the disk side in the File is getting read at once and then processed at once, the memory also should be very fast. Also in theory you have nowadays usually multicore systems so the CPU Utilization which is I guess is currently 1 core only could be some more cores - some more possible MP3 decoder performance.

Even Audacity takes about 3 Seconds do decode & display a 10 MB MP3 File, so even this already well developed tool needs some Seconds to draw the Waveforms.

If you are dealing with for example a not so frequently changing library or dealing with Files where you acces the Waveforms multiples times then I would also recommend like drugoimir suggested to decimate an cache the Waveform data so you don't have to go through the whole decode/calculate peaks/draw procedure every time.
Logged
fmcoder
Posts: 386


« Reply #7 on: 26 Jun '12 - 09:39 »
Reply with quoteQuote

My program already using CPU cores - decoding on 2 threads. Probably I should do 4 threads because many people already have 4+ core cpu's so at least they will have more speed Smiley

Maybe it is possible to somehow perform a low-quality decode of MP3?

Caching is not a good solution in my case, people add new tracks to the library and want to edit how they played - that's when the waveform is displayed, eg. they anyway need to wait those 2 seconds... And probably this will be the only time they need this waveform.
Logged
Pages: [1]
  Reply  |  Print  
 
Jump to:  

Powered by SMF 1.1.18 | SMF © 2013, Simple Machines