#1 Burning Software

It is currently Fri Dec 20, 2024 7:16 am

All times are UTC




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Delay after calling DiscAtOnce
PostPosted: Fri Mar 18, 2005 8:11 am 
When burning an Audio CD, after calling either
StarBurn_CdvdBurnerGrabber_DiscAtOnceRawPWFromFile
or
StarBurn_CdvdBurnerGrabber_DiscAtOncePQFromFile,
there will be a long delay. I guess it is processing the audio file(MP3), but I can't find a way to mesure the progress.

The delay is a little too long if there is no way to show a progressbar. Please advise.


Top
  
 
 Post subject: Re: Delay after calling DiscAtOnce
PostPosted: Fri Mar 18, 2005 11:42 am 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
After recording user data StarBurn SDK in DAO modes record manually lead-out. It's 16 megabytes in size (and do not forget about drive internal cache - it's 2-8 megabytes also and during "sync cache" operation it's also recorded to the CD media). So quite noticable delay (slower drive burns - more itme it takes to burn 18-24+ megabytes) at the end of the story is possibly. However you can easily calculate it using ( 16 MB constant + buffer size ) / burning speed. We can also add a callback indicating lead-out is now recording (with passing it's size as we do for general data track).

Let me know is it OK for you and what do you think.

Layman wrote:
When burning an Audio CD, after calling either
StarBurn_CdvdBurnerGrabber_DiscAtOnceRawPWFromFile
or
StarBurn_CdvdBurnerGrabber_DiscAtOncePQFromFile,
there will be a long delay. I guess it is processing the audio file(MP3), but I can't find a way to mesure the progress.

The delay is a little too long if there is no way to show a progressbar. Please advise.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Mar 22, 2005 5:51 am 
Looks like I hadn't made myself clear.

I meant when burning Audio CD, immediately after calling those DAO functions but before actual data burning is started(even before CN_WAIT_CACHE_FULL_BEGIN is reached), there is a long delay of over 30 seconds, during the delay period, the harddrive LED blinks like crazy.

How to measure this time period?


Top
  
 
 Post subject:
PostPosted: Wed Mar 23, 2005 12:40 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
Got it now! See, to burn disc in DAO mode you should always be clear upon exect track sizes in logical blocks (sectors). B/s you're writing lead-in with TOC information (and track lenghts) before writing actual data. With MP3 (and some other compressed formats) that's a problem. B/s you never know EXACT size of the uncompressed file payload. That's why before burning you need to play MP3 file very fast (as fast as machine can decompress MP3 stream) to get EXACT size of the file (uncompressed). That's what your machine is busy with :) Unfortunately this process is undeterministic from the time frame point of view. All we can do - report idividual file time get processing via callback. Would it be enough for you?

layman wrote:
Looks like I hadn't made myself clear.

I meant when burning Audio CD, immediately after calling those DAO functions but before actual data burning is started(even before CN_WAIT_CACHE_FULL_BEGIN is reached), there is a long delay of over 30 seconds, during the delay period, the harddrive LED blinks like crazy.

How to measure this time period?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 24, 2005 1:35 pm 
How can I do this? I can't find a callback number for this in the document.

anton (staff) wrote:
...All we can do - report idividual file time get processing via callback. Would it be enough for you?


Top
  
 
 Post subject:
PostPosted: Thu Mar 24, 2005 1:42 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
They are not implemented yet. I've asked - would it be enough for you? If yes - I'll add this stuff ASAP.

Layman wrote:
How can I do this? I can't find a callback number for this in the document.

anton (staff) wrote:
...All we can do - report idividual file time get processing via callback. Would it be enough for you?


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 24, 2005 1:51 pm 
It would be nice if you can implement this feature.30 seconds of darkness is a little too long for the end user.

anton (staff) wrote:
...All we can do - report idividual file time get processing via callback. Would it be enough for you?
[/quote][/quote]


Top
  
 
 Post subject:
PostPosted: Thu Mar 24, 2005 8:50 pm 
Offline
Site Admin

Joined: Fri Jun 18, 2004 12:03 am
Posts: 4089
Location: British Virgin Islands
Agree. Deal, so when I'll be done I'll notify you about preview version so you'd be able to check it out.

Layman wrote:
It would be nice if you can implement this feature.30 seconds of darkness is a little too long for the end user.

anton (staff) wrote:
...All we can do - report idividual file time get processing via callback. Would it be enough for you?
[/quote][/quote]


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group