Topic: Strange issue when "ripping" audio tracks from CD with newer versions of BassCD

[nadia]

Hello, 

I've been using version 2.4.5 of BassCD since its release in order to rip audio tracks from CDs and all worked without problems.
I essentially create the stream using the BASS_CD_StreamCreate function then I loop till the end of the track using the BASS_ChannelGetData function and store ripped audio data on disk.
Recently I upgraded to version 2.4.7 (and also 2.4.8 does the same) and I noticed that, during the reading loop, quite often the BASS_ChannelGetData function returns 0, meaning that something different happened (): if I sleep for a couple of seconds (using SleepEx function) then retry the BASS_ChannelGetData function it will go on: is this something expected or may be a symptom that some kind of regression happened?

Kind regards 

nadia

[Ian @ un4seen]

Since BASSCD 2.4.7, data is read from the CD asynchronously, while earlier versions read synchronously. This means an update thread now can't be delayed by a slow read during playback of a CD track. And in the case of a decoding channel (like yours), it means BASS_ChannelGetData will return what data it currently has available (it'll actually wait up to 100ms) rather than waiting until more arrives. This shouldn't cause any problems if you check for a return value of -1 (not 0) to detect the end, and it will allow you to exit a decoding loop more quickly if you want to do so. For example:

Code: [Select]

while (!stop) {
BYTE buf[20000];
int got = BASS_ChannelGetData(handle, buf, sizeof(buf));
if (got == -1) break; // reached the end/failed
}


[sveakul]

@nadia: we recently went through the same thing with the MusicBee player, where versions greater than 2.4.6 could not be use to make "secure rips with error recovery" without producing files full of errors.  This must be due to what Ian describes here as what happens when a slow read occuring during playback is not able to delay the update thread.  Secure rip involves slowing down the read speed during a rip when the feature feels the need to confirm and/or attempt repair of possible errors.

If you add the code Ian supplied here to 2.4.8, please post on what your results were.