Topic: BASS_FX returning empty reverse stream on 24-bit files

[lqbe]

I have a problem with BASS_FX returning an empty stream on certain files (tested with some 24-bit 44.1 mono wavs).

Stream works flawlessly in any situation, is created with BASS_STREAM_DECODE | BASS_SAMPLE_FLOAT, waveform peaks are created from the output. Creating a reverse stream and leaving it as it is works as expected: waveform is reversed. However, when using BASS_ChannelSetAttribute( channel, BASS_ATTRIB_REVERSE_DIR, BASS_FX_RVS_FORWARD ); directly after reverse stream creation it works for most files, but some files will simply fail. BASS_ChannelGetData( reverse_stream ) returns 4 bytes (1 float sample) on the first call, and -1 on the second call.

This behavior can consistently be reproduced with certain files and only happens when setting BASS_FX_RVS_FORWARD after creation (to default to a forward playing stream).

Any help is appreciated. Jobnik?

[lqbe]

I have pinned down the cause:

This happens exclusively with 24-bit audio files (tested with wavs), always with 24-bit mono files, most of the time with 24-bit stereo files.

[Ian @ un4seen]

I wasn't able to reproduce that here, so please upload a WAV file that you are having the problem with:

   ftp.un4seen.com/incoming/

Also confirm what "dec_block" parameter you are using in your BASS_FX_ReverseCreate call, and that you are using the latest BASS and BASS_FX versions.

[lqbe]

dec_block is set at 2.0f, but fails equally with any other value. Stream flags are DECODE and FREESOURCE.

Tested again with the stuff versions of bass/bass_fx just to be sure, same behavior. I've placed a lqbe_...zip in your /incoming with some code and several 24-bit files (wave, aiff), which all behave the same way: decode return 4 bytes, then -1. The first case (see .cpp) always fails on 24-bit files, the second case works on all files.

[Ian @ un4seen]

That's strange, I couldn't reproduce the problem with those files either. I was using the current release versions of BASS and BASS_FX from the BASS webpage, with a modified version of the WRITEWAV example. Here is the modification for you to try there:

   www.un4seen.com/stuff/writewav-reverse-forward.exe

The code modification is the addition of this just before the "fopen" call (and a DLL version display):

Code: [Select]

chan=BASS_FX_ReverseCreate(chan, 2, BASS_FX_FREESOURCE|BASS_STREAM_DECODE);
BASS_ChannelSetAttribute(chan, BASS_ATTRIB_REVERSE_DIR, BASS_FX_RVS_FORWARD);


[lqbe]

Works with your executable. I tried to find differences, but there is really not that much to compare and it fails consistently in my builds.

I have uploaded another file (lqbe..._test_program.zip) with two executables (run either one on both wavs, any on any of the other files I've uploaded yesterday) with the full code. Please let me know what your result is.

[Ian @ un4seen]

Ah, I see the problem now. It is related to the FPU precision setting, which is resulting in the WAV file length value being a sample short in your EXE's case. Here's a BASS update to prevent that happening:

   www.un4seen.com/stuff/bass.zip

Let me know if you still have any trouble with it.

[lqbe]

Brilliant And yes, this gets rid of the problem and behavior is as expected now in both compilers.
Thanks Ian!

[lqbe]

A few other issues came up:

Running the reverse stream in forward mode through a decoding/resampling mixer, should that be okay?

I noticed position seeks (initial position of a reverse forward mixer source) to fail sporadically, i.e., seek to the wrong position (almost a rounded start position).

Setting a mixtime BASS_SYNC_POS to stop decoding of the reverse forward source (BASS_ChannelStop( source )) does not trigger at the right position (the same position it would trigger at in a regular BASS stream) in the stream, so a BASS_MIXER_END mixer won't end properly. It usually triggers too late, leaving extra audio behind the trigger pos.

Repetitive seeking (e.g., looping of portions) in a reverse stream in reverse mode causes a diverse array of GPFs in bass_fx.dll, and sometimes going deeper down the call stack to msvcrt/ntdll. Easily reproducible by variying the loop portion and seeking back to the new start position (think changing a loop while playing) continously.

All tested with accurate prescans, and mostly on 16/24-bit uncompressed wave files.

Edit: Verified with two compilers, on three different systems.

[lqbe]

On jobnik's site (didn't notice it had a forum) I just read about an upcoming release:
"Reverse: Fixed small bug in reverse processing, that BASS_SYNC_END syncs aren’t getting triggered on reverse streams that are playing some files forwards."

This sounds like a fix to one of these issues, but cannot confirm yet.

[Ian @ un4seen]

Are you making the BASS_ChannelSetPosition/SetSync/Stop calls on the reverse stream rather than its source? If not, please try that.

[lqbe]

I'll give it a go and get back here when I have some results. (Might take a bit.)