#1 Burning Software

Hello

I'm trying to understand the cause of a delay using the StarBurn OCX (not StarBurnX, which I can't use yet due to missing OGG VORBIS support).

I do all of my checks, setup the write speed, turn on BUP, and perform OPC. Then I call the method to create an Audio CD.

The whole process takes about 5 minutes on an Athlon 2800+ with 1GB of RAM using a 35-minute WAV file (44100 16 Stereo).

Less than 3-minutes of this is the burn process and more than 2-minutes is a delay that happens on every write. During this time, my process increases in size by dozens of megabytes and the memory is released immediately after the burn.

My questions are:

1. What causes this delay?
2. Is there any way to get status on the progress of this delay?
3. Is there any way to eliminate or reduce this delay?

Programs like Nero start the burn immediately without any delay and I'd like to achieve something similar using StarBurn.

Many thanks
- Shaun

Please send to us StarBurn.log.
How to generate StarBurn.log please read StarBurn_FrequentlyAskedQuestions.pdf (page3 "How can I enable debug logging with StarBurn?")

Hello

Shaun, generally speaking the StarBurnX supports the OGG Vorbis format The StarBurnX provedes some 'vorbis' dll's (../StarBurnX/bin/.. - ogg.dll, vorbis.dll, vorbisfile.dll). As our installation script has little mistake you should copy these dll's into forlder of your application manually or update the PATH ev.var. (PATH= ...; ../StarBurnX/bin/)

Note that StarBurnX (as and StarBurn SDK does not support the 'MONO' OGG Vorbis files)!!

Thanx

Dmitry

The line it stalls on is:



When it finally starts to burn after a few minutes of delay, the log gets this line:



Where would you like me to send the full log?

Thanks
- Shaun

I found something else.

During the stalled period, StarWave.log grows by about 5MB - reaching the height of its increase just before the actual burn begins. I erased the file and examined it's progress on the next burn.

The log repeats over and over and over again except for the number changing on this line:



I'm starting to wonder if it's buffering the whole CD audio image before it starts the burn process.

We're golden! You steared me to the log files and in noticing the StarWave.log file I started to see what was happening.

device.SetCacheBufferSizeInMBs(16);

This worked brilliantly! Thanks!
- Shaun

We don't need the log for this. It's *NORMAL* behaviour of the StarBurn core.

No we don't buffer all the content. Just as much as software cache you've allocated for the burning.

16MB is very small size. Stick with default 160 MB one for CDs and go for 256-512 for DVDs at the hightest burn speeds.

The difficulty in sticking with 160MB is that it nearly doubles the burn time on a disc.

I'm trying to write a software that will work similar to a CD Duplicator with a Hard Drive - which starts the burn instantly. And for software duplication, many people are using Nero - which has no delay even with MP3 files.

Would 32MB be a happy medium?

Probably I will let the end-user set the buffer size of their choosing.

Thanks again
- Shaun

1) I don't understand how increased buffer capacity increses burning time...

2) No.

3) Good idea. But providing too small one will make your software producing coasters. Or poor quality discs.

I've built a test application that allows me to "race" various burning operations and what I found was this:

Leaving the buffer alone (so default of 160MB) causes about a 2 minute lag between calling the method to begin the write process (CreateCD if memory serves) and the time when the first callback occurs. The burn then takes about 3:05 with my particular test file. So about 5 minutes in total. During the two minute lag, the memory usage of the EXE file grows by about 160MB.

Setting the buffer to 16MB causes about a 20 second lag between calling the method to begin the write process and the time when the first callback occurs and the total write process takes about 3:30.

That doesn't seem like much difference but a 33% decrease in burn time is a good thing.

What I want to include in my log is a search for buffer levels to make sure that I'm not getting into buffer underruns. Perhaps that is happening.

Your CPU is slow that's why. During buffering period we do decode some part of the content and put it into the FIFO. When burning starts decoding and burning goes in parallel. So for SMALL discs you'll have a benefit with small buffer (no delay). But quality is a question. For complete CDs on fast CPU you should not have much of the difference.

I've got an Athlon 64 CPU running at (I believe) 3ghz. Mind you, it's running XP Home and not taking any advantage of the 64-bit features.

What CPU would you recommend to greatly reduce or eliminate delays?

Thanks again
- Shaun

It's not your issue in such a case............................