#1 Burning Software

My goal is to perform on-the-fly compression (wma) of audio CDs. I see I can do this pretty easily using StarburnX and the GrabTrackAsAudio function. However, we are currently using the starburn.dll for burning and would prefer to stay with this rather than include the StarburnX dll. It appears the route would involve using the StarWave functionality, but this just provides conversion of an already grabbed wav file. I've trolled the board and sdk manual, but can't find a sample to demonstrate a direct grab from a CD drive to compressed audio file. Can you recommend a sample or place in the manual to look for try to mimic the GrabTrackAsAudio function using the starburn.dll functions? I'm developing in .Net (C# or VB.Net).
Thanks.

Hello,

1) It seems starburn.dll ( StarBurn SDK) does not provide the magic function smt. like GrabTrackAsAudio you should use ( at least ) the next two functions :

StarBurn_CdvdBurnerGrabber_GrabTrack and StarBurn_StarWave_UncompressedFileCompress.

2) Look into the MSVS C++ examples - AudioGarabber and AudioCompressor ( they are located in the \Samples\StarBurn Core\MSVC\ folder )

Regards,

Dmitry

Dmitry,
Thanks for your response. I originally thought the GrabtrackAsAudio was performing an on-the-fly conversion in the sense that it was encoding chunks as it grabbed the wav file. From the source in the MSVS samples it appears it grabs the entire wav file before sending it for compression. This is fine, I just had it wrong in my mind.

I've implemented the GrabTrack and it works fine, but I'm having a problem with converting the StarBurn_StarWave_UncompressedFileCompress function to C#. The following are the pieces of code I'm using. The problem is I'm not sure how to properly define the PSTARBURN_STARWAVE_CALLBACK parameter. I was hoping you may be able to provide some guidance.

I found the problem. I needed to change the ulong declarations to uint in the following.
public ulong CompressorCallback(
ulong p__ULONG__Reason,
ulong p__ULONG__Parameter,
IntPtr p__PVOID__Context)
{ return 0; }

Hello,

Hmmm it seems should be System.UInt32=>uint )

Regards,

Dmitry,
I'm making progress but decided to take it a bit further and have bumped into another problem. Rather than grab the wav file and then send it to the compressor, I'd like to do this on the fly. I see now that the StarBurn_CdvdBurnerGrabber_GrabTrackEx function has a call back with the data chunks as it rips. I assume then I can compress these on the fly by first creating the CompressedFileWriterObject when the p__PSTARBURN_CreateFILE_CALLBACK is called and then actually compress the chunks when the p__PSTARBURN_WRITEFILE_CALLBACK is called using the returned value of lpBuffer and nNumberOfBytesToWrite from the callback.

The problem is when I attempt to compress the chunk using the StarBurn_StarWave_CompressedFileWriterObjectWrite function with these 2 values I keep getting a "Header is bad" error. I believe I'm creating the CompressedFileWriterObject properly since the LOG shows it being created properly. Below is the snippet from the log when I call the StarBurn_StarWave_CompressedFileWriterObjectWrite function using:
parameters:
previously created CompressedFileWriterObject
lpBuffer (exact value returned in the p__PSTARBURN_WRITEFILE_CALLBACK)
nNumberOfBytesToWrite (exact value returned in the p__PSTARBURN_WRITEFILE_CALLBACK)

Again, I'm trying to do this in C#. Any idea why I would be getting this error?
Thanks.

StarWave_CompressedFileWriterObjectWrite(): >>> ENTERed
StarWave_CompressedFileWriterObjectWrite(): p__PVOID__CompressedFileWriterObject == 0x013BAB64
StarWave_CompressedFileWriterObjectWrite(): p__PVOID__WriteDataBuffer == 0x08C3C4A4
StarWave_CompressedFileWriterObjectWrite(): p__ULONG__WriteSizeInUCHARs == 61152 ( 0xeee0 )
StarWave_CompressedFileWriterObjectWrite(): Header is bad, got 0x3cfff0 instead of expected 0x48435752, failed, status 87 ( 0x57 )
StarWave_CompressedFileWriterObjectWrite(): <<< EXITing with success

This means the pointer you pass as an object is invalid.

Thanks Anton, I wasn't handling one of the "out" parameters correctly, I've got it working now.

I've noticed the rip speed is pretty slow. I'm a little confused about the functions. I assume the GrabTrackEx function performs the error correction processes I've read about in the forum and potentially why it's a bit slow. Does the ReadRaw function perform the same type of error correction or is this a straight read? Is it any faster? The basis is an audio CD ripping program. I'm wondering if I should be using a different function than GrabTrackEx. I wasn't too clear as to the difference in GrabTrackEx, ReadRaw and ReadCooked, excepted that in the Read functions you can specify the specific sectors.
thanks

Slow - is very relative thing... 1) Did you set maximum possible performance before ripping? 2) Do you have other programs ripping CDs much faster?
Error correction is not used with AudioCDs as there's no such thing as "error correction" in context of AudioCD at all.

Anton, Thanks, you're correct speed is relative. I was testing with a ripping program called CDEX and it appeared to extract a bit faster, probably approx. 20-30% faster on the same PC with the same drives. I'm not sure this is a big deal, I just wanted to make sure I was using the proper functions for the job I'm trying to accomplish and there wasn't a better approach.

I must have missunderstood regarding the error correction. I was referring to an old post were you stated the following with regard to a question about accuracy of ripping. Maybe this is no longer relevant.



All said it seems to be working very well, both grabbing and compression.

Audio ripping software can use intermediate buffer (similar to what we do when burning) so they keep two threads, one ripping the data from the CD and storing it to the cycle buffer and other thread fetching the data from the buffer and storing it to the disk. We use one thread doing read and write sequentially so it could be *possibly* we're not that fast as special AudioCD ripping applications. Another point is still - setting maximum speed with StarBurn SDK before ripping

Anton, Thanks for the explanation.

I'm attempting to set the read speed using StarBurn_CdvdBurnerGrabber_SetSpeeds and using a value of 65535 for the read speed. I think I pulled this from a sample project. I assume this is correct.

When creating the grabberobject using StarBurn_CdvdBurnerGrabber_CreateEx, I'm setting the CacheSize to 32MB. I'm not sure if this matters or not. I see it set to either 1MB or 32MB in the samples. Would this effect performance?

It's for write only. We don't use cached reads.