Jump to content
  • Who's Online   0 Members, 0 Anonymous, 16 Guests (See full list)

    • There are no registered users currently online
  • 0

Toast Fails To Burn Every Time


Modular1

Question

13 answers to this question

Recommended Posts

Hmm, I cant imagine why bluetooth would matter either but I'll pass it along to my test labs (they have more systems, burners, and other items then I do). I personally do my testing on a MacBook Pro 2.33 GHz Core 2 duo system. Unfortunately I don't have the particular model EyeTV that you have (I have an EyeTV hybrid). We have another update scheduled for release soon and I have a pretty good feeling that some of the encoding issues that we have been having will be resolved in this update.

 

Thanks, John. That is good to hear.

 

The crashes are, typically, either a kernel protection fault or an invalid address issue. It appears that Toast is attempting to access protected memory or that the OS X memory controller is not preventing it from attempting to do so. I found a reference on the internet some time back that another application was encountering similar crashes for that reason. I have 2 GB of installed RAM and most of the time have in excess of 512 MB of it unused (even though there are numerous page in/page out operations under way) so I do believe that Apple needs to take a look at the memory manager.

 

Note: My hardware has been extensively tested by both myself and the people at the Apple Store.

 

 

 

Link to comment
Share on other sites

My wild guess is that you're trying to burn existing MPEG 2 videos that have timecode breaks. If this is true then you need to use MPEG Streamclip to fix the timecode breaks so that Toast can properly read the entire video file.

Link to comment
Share on other sites

John,

 

Yes, the speed difference is with the exact same media. I have not included either the multiplexing time (or lead in/lead out time) or the verification time. Toast reports the speed differences in the average and current speeds displayed. The differences are not inconsequential.

 

Unfortunately, since the upgrade to OS 10.5.3 Toast crashes very nearly 100% of the time when writing (not multiplexing) and EyeTV file to a DVD disc. I am able to save the file as a (.toast) disc image file, but when I write it to a disc Toast finds some error, real or imagined, with the disc during verification the overwhelming majority of the time. The error message that I get is not during the burn, but during verification.

 

Please see this related thread.

 

As to the apparent lack of verification of a file which has been multiplexed because Toast has nothing to compare the disc to, Toast is supposed to maintain the file which has been burned (in this case, in its multiplexed format) until Toast is either closed or another file is imported and the current one deleted. It does not do so (even though Roxio sales representatives persist in stating that it does) since at least Toast 7 to my personal knowledge. When I remember to, I put "2" as the number of copies to be burned so that, in the event of an actual, though very unusual, media failure the multiplexed file is actually maintained and burned from when another piece of media is inserted.

 

There is not sound reason that this bug has not been fixed. It was reported...several years ago, but that is the very least of the problems with Toast at the moment.

 

In any event, this leaves me in the position, once again of having to drag out my Tiger drive with Toast 7 to make burns from it if I actually want to get things done.

 

Richard

 

Can you post a file somewhere that I can download and test with. I am unable to replicate the problems that you describe.

 

Link to comment
Share on other sites

Maybe I can try to recreate a file with similar properties. What is the source of the files that you are using?

 

 

John,

 

I am recording the (analog) output from a Scientific Atlanta 8300HD (Time-Warner Cable) by running it through an EyeTV 250 Plus functioning as an analog to digital converter and is recorded on my Mac with El Gato's software, EyeTV. I have used an EyeTV 200 as well as the EyeTV 250 Plus. The software I am presently using is EyeTV 3.0.2, although I will occasionally revert to EyeTV 2.5.2 and Toast 7.1.2 in Tiger or 7.1.3 in Leopard to try to deal with a troublesome file.

 

The file is EyeTV is presently a .eyetv file which is actually some form or other of mpeg file. When I go to burn a file to disc I right click (or control click) on the file I want in the listing in EyeTV and select "Toast". I then add whatever name information and so on to the file that I want and click the big red "burn" button.

 

With files that have been recorded since the OS 10.5.3 update they normally progress through the multiplexing phase, but crash at some point during the write to disc. If I save the file as a (.toast) disc image, the file will normally proceed through the write to disc phase, but fail verification at some point.

 

I am presently burning a file that was recorded prior to the OS 10.5.3 update to see if the result is any different.

 

I will report back about it shortly.

 

Richard

 

 

 

Link to comment
Share on other sites

Hello again John,

 

I took a while longer to get back to you as I think that I found out what was going on. I had previously identified an issue with Toast apparently attempting to make use of protected memory which resulted in crashes (typically either a kernel protection fault or invalid address) which I believed to be associated with the use of Bluetooth.

 

When I was booting back into OS 10.5.3 to try to burn the file which I had recorded prior to the OS 10.5.3 update I noticed that Bluetooth was turned on. I guess that it must have gotten turned back on during the update process. I turned it off and burned the file which I had previously burned without incident. It went to completion without difficulty. Next I tried burning a file which had been recorded after the update and which I had experienced problems with earlier. It burned to completion. I got busy and burned a number of other files to free up some space on my video data drive which had proceeded to get filled up when I was not able to burn DVDs successfully.

 

Exactly why there should have been apparent discrepancies between the burned DVD disc and the .toast file which resulted in a verification failure during that process because of Bluetooth being turned on I have not yet figured out. It does not really make sense, at least to me. Perhaps the "errors", be they real or imagined, are present in the burned DVD that is not subjected to the verification process. Perhaps they are not actually errors at all. I do not know.

 

What Mac are you using to test with? Mine is a MDD dural 1.42 GHz FW800 which has been extensively tested by myself and the people at the Apple Store's Genius Bar during my earlier problems to determine if there was any hardware issue that could have been contributing to the problem. I have the Apple Bluetooth and Airport modules installed. Anyway, you might see if turning Bluetooth on results in any change in how things work on your Mac. It would not hurt if you were to pass this on to your engineers for their evaluation.

 

Richard

Link to comment
Share on other sites

This may sound stupid, but it is what happened to me. I created 4 coaster with an error message of medium error, after it would do write in, the go directly to write out. I was trying to use Memorex DVD-R. On a whim I tried Maxell, and dang if it didn't burn like it should. Make sure you have good media. I thought mine was good, but...

Link to comment
Share on other sites

The verification process simply checks the burned disc against the source data. If any conversion or encoding needs to be done to the file, there is no way to compare it to the original. Thats the only difference in the process. If there is an error that prevents the burn from happening properly, Toast will notify you during the burn.

 

 

Is this using the same media? This is not including the time it takes to encode the video, right? This is just the burn process. What are the differences in burn speed?

 

 

John,

 

Yes, the speed difference is with the exact same media. I have not included either the multiplexing time (or lead in/lead out time) or the verification time. Toast reports the speed differences in the average and current speeds displayed. The differences are not inconsequential.

 

Unfortunately, since the upgrade to OS 10.5.3 Toast crashes very nearly 100% of the time when writing (not multiplexing) and EyeTV file to a DVD disc. I am able to save the file as a (.toast) disc image file, but when I write it to a disc Toast finds some error, real or imagined, with the disc during verification the overwhelming majority of the time. The error message that I get is not during the burn, but during verification.

 

Please see this related thread.

 

As to the apparent lack of verification of a file which has been multiplexed because Toast has nothing to compare the disc to, Toast is supposed to maintain the file which has been burned (in this case, in its multiplexed format) until Toast is either closed or another file is imported and the current one deleted. It does not do so (even though Roxio sales representatives persist in stating that it does) since at least Toast 7 to my personal knowledge. When I remember to, I put "2" as the number of copies to be burned so that, in the event of an actual, though very unusual, media failure the multiplexed file is actually maintained and burned from when another piece of media is inserted.

 

There is not sound reason that this bug has not been fixed. It was reported...several years ago, but that is the very least of the problems with Toast at the moment.

 

In any event, this leaves me in the position, once again of having to drag out my Tiger drive with Toast 7 to make burns from it if I actually want to get things done.

 

Richard

Link to comment
Share on other sites

Like Guymer, I had very mixed results with Memorex media, but I think that there is something about the file that Toast does not like as tsantee concluded.

 

Toast seems, to me, inordinately sensitive to any little thing in a file that it thinks is a problem.

 

Among the many problems I have encountered with Toast 9, one that remains is that Toast will decide that there is something wrong with a particular block in a disc which I have burned from a disc image (.toast) file during the verification process. Unfortunately, Toast does not continue past the first such issue it finds which would give you some idea of whether it is just one such instance or whether there were a lot of "problems" with the disc.

 

I presently use only Verbatim media which, in my experience, has been decent media. That said there really is no way I am aware of to test a particular piece of media other than writing to it. If the write is successful it is presumably "good". If not, it presumably is either not good or there was some other problem during the write, but you never actually know.

 

You might try saving the video file as a disc image and then burn it to see if that makes any difference. Exporting the file as a stream clip is probably faster though.

 

For John at Roxio:

 

When burning directly from a file such as an .eyetv file there is no obviously apparent verification process. Does that mean that an "error" such as reported during the burning and subsequent verification process from a disc image file goes undetected?

 

Also, there is a substantial difference in the reported burn speed when burning a disc from a disc image file as compared to the reported burn speed when burning from the eyetv file which was used to create the disc image (.toast) file? Why is this? Once the file is multiplexed it would seem that the only limitation in burning speed should be the speed of the optical drive, but this does not appear to be the case.

 

Thanks

Link to comment
Share on other sites

When burning directly from a file such as an .eyetv file there is no obviously apparent verification process. Does that mean that an "error" such as reported during the burning and subsequent verification process from a disc image file goes undetected?

The verification process simply checks the burned disc against the source data. If any conversion or encoding needs to be done to the file, there is no way to compare it to the original. Thats the only difference in the process. If there is an error that prevents the burn from happening properly, Toast will notify you during the burn.

 

Also, there is a substantial difference in the reported burn speed when burning a disc from a disc image file as compared to the reported burn speed when burning from the eyetv file which was used to create the disc image (.toast) file? Why is this? Once the file is multiplexed it would seem that the only limitation in burning speed should be the speed of the optical drive, but this does not appear to be the case.

Is this using the same media? This is not including the time it takes to encode the video, right? This is just the burn process. What are the differences in burn speed?

 

Link to comment
Share on other sites

Hmm, I cant imagine why bluetooth would matter either but I'll pass it along to my test labs (they have more systems, burners, and other items then I do). I personally do my testing on a MacBook Pro 2.33 GHz Core 2 duo system. Unfortunately I don't have the particular model EyeTV that you have (I have an EyeTV hybrid). We have another update scheduled for release soon and I have a pretty good feeling that some of the encoding issues that we have been having will be resolved in this update.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...