Author Topic: Some audio samples are lost ... somewhere inside BASS.  (Read 1322 times)


  • Posts: 160
I have emulated a sort of turntable with BASS for fine-tuning my detection algorithm.
It works most of the time, sometimes it doesn't. It does start by finding zero-crossings.

After searching and many tries,
I just found out that BASS was not outputting all of the audio data !!

It's a 44.1/16 WAV file which has exactly 34 samples of silence at the beginning,
with BASS I only get 1 sample at the beginning.

Though this not being my main problem, it raises another question;
as the beginning is incorrect, why should the rest of audio data all correct ?
By doing some statistics (when playing file thru BASS), there are some places in the audio file that yields out of range results while they're not.

This is the 'turntable' with BASS, I process my audio inside a DSP.

Code: [Select]
           _ptrTc = Bass.BASS_StreamCreateFile(fileName, 0, 0,
                                                BASSFlag.BASS_STREAM_DECODE | BASSFlag.BASS_STREAM_PRESCAN);
            if (_ptrTc == 0)

            _ptrReverse = BassFx.BASS_FX_ReverseCreate(_ptrTc, 2f, BASSFlag.BASS_STREAM_DECODE);
            if (_ptrReverse == 0)

            _ptrTempo = BassFx.BASS_FX_TempoCreate(_ptrReverse, BASSFlag.BASS_FX_FREESOURCE);
            if (_ptrTempo == 0)

I am processing shorts for now, though I'm not sure going to floats would fix my issue.

Could it be related to resampling/dithering that is applied by the BASS_FX_Tempo stream ??

Thanks for helping me solve this critical issue  ;D

Thank you,


  • Posts: 160
I think I found the culprit, you might want to check this :
Wavelab can save .WAV with a bigger header and some data the end too.

It seems BASS is a little confused on where the file starts exactly.

Ian @ un4seen

  • Administrator
  • Posts: 21314
Please upload an example troublesome file to have a look at here...

Also, to determine whether the problem is caused by the tempo and/or reverse processing, does it still happen if you remove those calls?


  • Posts: 160

I have tested what you said.

- A non-standard WAV header is well understood by BASS, I was wrong ...  ;D
- Feeding my app. with a standard stream fixed the issue, all zero bytes on start are present. (Though I can't really test my app. anymore as its purpose is to detect the pitch and position.)

There's another issue I just found out by testing now,
Code: [Select]
BassFx.BASS_FX_ReverseCreate(_ptrTc, 2f, BASSFlag.BASS_STREAM_DECODE);When the file is less N seconds than the seconds parameter dec_block, output is all zeros, everytime ...

(I sent you Timecode.WAV in your FTP)

Thank you !

P.S. I wanted to ask you something that is related to my issue though it's not related to BASS.

As you've seen in the WAV, there are positions coded on left channel (1,2,3 ...)
I am apparently facing a much higher level issue in detecting the bits;
what I do is I get local RMS between each crossing VS global RMS, it works pretty well for most bits;
(they are detected as high or low) but sometimes they are at half hence,
I lose synchronization as they're badly translated.
From what I've read, it seems to be some sort of jitter due to being in a discrete time-domain...

Do you have any ideas ?

Thanks a lot  :)
« Last Edit: 3 May '10 - 17:56 by aybe »

Ian @ un4seen

  • Administrator
  • Posts: 21314
- Feeding my app. with a standard stream fixed the issue, all zero bytes on start are present.

OK, and to narrow it down further, what about if you leave in only one of the tempo or reverse processing?

As you've seen in the WAV, there are positions coded on left channel (1,2,3 ...)

I'm afraid I don't see that :)

I see 5 cue points near the start, but I guess you're referring to some signal in the sample data?


  • Posts: 160
Hello !

  • The culprit is the tempo stream, not the reverse stream.
  • The markers where only here so that Wavelab saves them in the WAV header to produce a non-standard one.

The position I am referring to, are the higher and lower periods
you see on left channel; it's a 21 bits timecode that goes 1,2,3, etc ...
I've been searching the web again and apparently there seems to be
some very subtle things in decoding digital data signals;
people seems to implement convolutional codes and some other things
as apparently signal gets degraded throughout medium it's transmitted,
thus it needs some error correction.

But I am sure there's a much easier way since when I started detecting the playing pitch,
it went very tricky to be able to difference pitch changes of 0.25 Hz
(Which equals 0.02% which is the finest resolution on a Pioneer CDJ-1000)
I found litterally dozens of methods for detecting pitch from FFT to
Wavelets and many others but they were all beyond my maths knowledge.

I finally ended up with an instant-reaction pitch detection that is very accurate and
doesn't involve more than very basic mathematics, hence not CPU hungry.

If you have an idea, you're welcome !!!

Thank you  :D