SuperDrive on MacBook not working well

[Heb1228]

That's not true. What do you think causes dropped frames?

I don't have dropped frames in any video I've ever output with Final Cut. With real-time display, sure, but that doesn't have anything to do with encoding tasks.

 

[matticus008]

I don't have dropped frames in any video I've ever output with Final Cut. With real-time display, sure, but that doesn't have anything to do with encoding tasks.

Then you're fortunate. But it does happen, and it's caused by low available RAM or a tie-up in the I/O system. Loss of sound bits (or whatever the proper audio term is) happens the same way, as does the occasional playback stutter in iTunes or QuickTime. The system is far from bulletproof, and while rare, encoding can fail, especially when the computer is tossing large files around and the installed RAM is being used by other applications.

 

[Heb1228]

If that were true... my Powerbook should do a better job encoding music/video than my iMac. Other than the iMac taking longer, the output is exactly the same.

You really need to provide some documentation for this theory... cause I think you're making it up.

 

[matticus008]

If that were true... my Powerbook should do a better job encoding music/video than my iMac.

Why? If both computers are capable of running the software, then the PowerBook would simply be faster. But if your PB ran out of RAM, you'd drop frames and have failed encodings, same as if your iMac ran out of RAM. It's not spec-dependent, it's available resource dependent. An iBook and a quad PowerMac are both capable of dropping frames and not successfully encoding from time to time.

You really need to provide some documentation for this theory... cause I think you're making it up.

I'm making up dropped frames, beach balls, and playback stutters?

 

[neocell]

Agree to Disagree, and move on 😉

 

[jesusphreak]

Well it certainly isn't having any problems with the OSX discs...

 

[Heb1228]

An iBook and a quad PowerMac are both capable of dropping frames and not successfully encoding from time to time.

Like I've said several times above... dropped frames during playback has nothing whatever to do with encoding.

I defy you to show me a video that dropped frames during the encoding process.

Well it certainly isn't having any problems with the OSX discs...

Hopefully a clean install will fix the problem then! Good luck. And sorry for hijacking your thread.

 

[matticus008]

Agree to Disagree, and move on 😉

It shouldn't be a disagreement at all. It's an objective, technical reality.

If it's absolutely necessary (though it shouldn't be), here's a link to causes of dropped frames in capturing video. The importance of these components changes somewhat when encoding video or when working with audio, but that's a fairly comprehensive list of the "cast of characters."

Like I've said several times above... dropped frames during playback has nothing whatever to do with encoding.

I defy you to show me a video that dropped frames during the encoding process.

1. Yeah it does. Say you have a DV source and you try to convert it to H.264 on a weak system. It'll drop frames. That encoded video will have dropped frames whether it's played back on that system or copied over to a fully loaded PowerMac, because it lost data in the conversion process.

2. If I gave you a video with dropped frames, how would you be able to tell whether it was caused by playback or encoding without having the raw footage on the camera to compare it?

 

[Heb1228]

If it's absolutely necessary (though it shouldn't be), here's a link to causes of dropped frames in capturing video.

Capturing video is also a completely different question. The reason frames can be dropped in capture is because the tape plays at a fixed rate.

Thats completely different than encoding from one file to another through a software encoder (like Quicktime). Like I said, I defy you to show me an encoded video that has dropped frames in it. Can it happen in the capture process? Sure! In the playback process? Sure! But it does not happen in the encoding process!

 

[Heb1228]

1. Yeah it does. Say you have a DV source and you try to convert it to H.264 on a weak system. It'll drop frames. That encoded video will have dropped frames whether it's played back on that system or copied over to a fully loaded PowerMac, because it lost data in the conversion process.

Nope. the only dropped frames are in playback. On a faster machine, it'll play back perfectly.

2. If I gave you a video with dropped frames, how would you be able to tell whether it was caused by playback or encoding without having the raw footage on the camera to compare it?

Because I could look at the frame rate in the Quicktime info window to make sure it wasn't dropping frames on playback. Easy enough?

 

[matticus008]

Nope. the only dropped frames are in playback. On a faster machine, it'll play back perfectly.

Prove it. If that's the case, why can't low end computers encode H.264? Why do some codecs produce horrible video and others work fine on the same system?

 

[Heb1228]

Prove it. If that's the case, why can't low end computers encode H.264?

They can encode it. They just can't play it back. If you want I'll encode a video on my 450 iMac and let you see that it plays back perfectly on a faster computer.

Why do some codecs produce horrible video and others work fine on the same system?

huh? because some codecs are better than others.

 

[matticus008]

They can encode it. They just can't play it back. If you want I'll encode a video on my 450 iMac and let you see that it plays back perfectly on a faster computer.

I'd like to see documentation on frame dropping "never" occurring during encoding. There's a reason you never see encoding (edit)an HDV source to high-definition H.264 without data loss on a system with <256MB RAM and/or <400MHz CPU. You've yet to demonstrate that running out of RAM or an I/O stutter (i.e. reasons for buffer underruns) can't result in a failed or corrupted encoding. I'm not going to go back and forth on this, because that's just how computers work.

huh? because some codecs are better than others.

Yes, and the better codecs won't run adequately without the muscle to lift them. Encoding to 320x240 MPEG is going to be a lot easier on the system than pumping out 1080p from HDV tape. You think that a 300MHz iBook with 128MB of RAM could do it?

 

[Heb1228]

I'd like to see documentation on frame dropping "never" occurring during encoding. There's a reason you never see encoding a DV source to high-definition H.264 without data loss on a system with <256MB RAM and/or <400MHz CPU. You've yet to demonstrate that running out of RAM or an I/O stutter (i.e. reasons for buffer underruns) won't result in a failed or corrupted encoding.

Look man, you just don't know what you're talking about. Here's how I'll prove it.

My iMac is currently working on converting a 1 minute DV clip to the higher quality H.264 setting in Quicktime sharing preferences. I've also got 14 apps open on the machine and less than 10MB of free RAM showing in Activity Monitor. In fact, I'll even start some audio files playing in iTunes.

It will take longer than a faster machine, but the quality will be the exact same as if you did it on your powerbook or if iGary did it on his Quad with 8GB of RAM.

And BTW... there is a reason

you never see encoding a DV source to high-definition H.264

And if I have to explain it to you, then its no wonder we're having this conversation.

I'll post the finished clip tomorrow (since I'm going to bed and its going to take awhile). Then you can DL it, watch it, and post back admitting that I'm right. 😛

 

[jesusphreak]

So....

I got OSX reinstalled, popped in my CD and started importing (no apps open, 128k AAC).

Running along just fine, first 7 songs get imported without a hitch. Gets about 3/4ths of the way into the next song running along at 8.7x speed and out of nowhere it just hangs and the drive starts spinning.

Had to force quit to get iTunes to close. Guess I'll be calling Apple Support tommorrow, no clue what the problem may be. Makes no sense that it'll work well at first and then after a certain amount of time just stop.

 

[Heb1228]

Had to force quit to get iTunes to close. Guess I'll be calling Apple Support tommorrow, no clue what the problem may be.

I agree thats very odd. Sounds like its gotta be faulty hardware.

 

[matticus008]

Look man, you just don't know what you're talking about. Here's how I'll prove it.

My iMac is currently working on converting a 1 minute DV clip to the higher quality H.264 setting in Quicktime sharing preferences.

Well, you seem to be talking about transcoding, not encoding, so I'd watch the accusations. Also, you can't convert a DV clip to a higher quality--any change in quality is a downward one.

I've also got 14 apps open on the machine and less than 10MB of free RAM showing in Activity Monitor.

The way memory is managed in OS X, free RAM is relatively low in Activity Monitor at all times. I have just 100MB reported free right now, and the only apps I'm currently running are iTunes and Firefox. Reported free RAM isn't reflective of the system's capabilities.

Good night and have a fantastic tomorrow, but I'll still be waiting on a document that says that you can never, ever lose frames while encoding video, ever. Or if it's easier for you, one that says that RAM and I/O failures never cause data corruption.

I'm not saying that slow computers can't transcode files, or that playback on slow computers is always the same as fast computers, but I am saying that video and audio encoding does occasionally fail.

I agree thats very odd. Sounds like its gotta be faulty hardware.

On this, we agree completely. But we already knew that a dozen posts ago. 🙂

 

[Heb1228]

Also, you can't convert a DV clip to a higher quality--any change in quality is a downward one.

When I said higher, I meant higher than the "Small" or "Medium" H.264 settings in the output window. You were the one talking about encoding an HD clip from a DV original source a few posts ago so don't try it make it look like I don't know what I'm talking about.

but I am saying that video and audio encoding does occasionally fail.

iTunes encoding does not fail because of a slow data transfer rate from the optical drive. Or because RAM is full.

but I'll still be waiting on a document that says that you can never, ever lose frames while encoding video, ever.

Considering that its impossible to prove a negative, I guess you'll never see any such document. You're the one that needs to produce something saying that a slower machine results in lower quality video/audio encoding from the same source file. Because that's an absurd assertion.

 

[matticus008]

You were the one talking about encoding an HD clip from a DV original source a few posts ago so don't try it make it look like I don't know what I'm talking about.

HDV. Like you didn't know it was a typo.

iTunes encoding does not fail because of a slow data transfer rate from the optical drive. Or because RAM is full.

If the optical drive stalls or the RAM fills completely, the encoding DOES fail. I don't want to kick a dead horse here, but those are exactly causes of failed encodings.

Considering that its impossible to prove a negative, I guess you'll never see any such document. You're the one that needs to produce something saying that a slower machine results in lower quality video/audio encoding from the same source file. Because that's an absurd assertion.

That's not my assertion at all. I said that a resource failure can result in a corrupted recording. A resource failure can occur on a G3 iBook or a quad PowerMac. Proving a negative is not impossible, and in this case is required for your argument to make sense. I've given you a link listing the various system components that play a role in capture, encoding, and transcoding. A problem with any of them can produce bad files with varying degress of seriousness. Here are a couple more:

http://people.csail.mit.edu/tbuehler/video/MPEG-4.html
http://www.microsoft.com/windows/windowsmedia/howto/articles/enclfc.aspx
http://www.uemedia.com/CPC/2-pop/article_12199.shtml
http://support.dsny.com/cgi-local/perldesk/kb.cgi?view=69&lang=en

 

[jesusphreak]

I'm starting to think that the drive just overheats or something.

I reset the laptop to factory settings by removing the battery and holding down the power button. Then I popped my CD in and tried to rip the CD from where it left off last. Sure enough, 7-8 songs were ripped just fine and the drive was going along at 10.1x speed, then all of a sudden it just hit a point where it stoppped ripping and the drive started spinnings.

Its just not consistent. If it were about the scratches, the drive wouldn't be able to rip these same songs that it had been having problems with earlier and it wouldn't be having problems with songs it had no problems with previously.

I don't get it. I'm about to call Apple support and see if they have a fix.

 

[Mr. Anderson]

I've run FCP on a 450 MHz G4, 667 MHz TiPB, Dual 1.25 GHz G4 all with assorted bits of RAM and my Quad G5 with 8 Gigs of RAM and never had dropped frames during encoding or writing output. Occasionally during playback and capturing its happened, though.

But this whole discussion is OT for this thread, so start another thread specifically for the dropped frames discussion or just move on. Any more posts here that are OT will be deleted.

D

 

[codo]

Heb is correct - You won’t get dropped frames during encoding, it will all be there. It’s no different to running a programme in a way - It doesn’t just drop lines of code when it feels like it, it runs through it all until it’s done. The encoder just deals with one bit at a time and runs through the encoding process until it’s done - Its not CPU time dependent - There is nothing to drop to keep up with anything, it just chugs along.

However once encoded, its possible watching the file back could result in dropped frames depending on the speed of various hardware.


But more importantly, jesusphreak, I'd just phone Apple. Sounds like they’ve sold you something with a few issues, better get it checked out.

 

[jesusphreak]

Hmm, well I just pulled out a like-new CD from its case and the MacBook ripped the whole thing successfully. It just appears that the drive is sensitive to the most minute scratches? Is that really an issue or do I need to get some kind of CD polisher?

 

[codo]

Hmm, well I just pulled out a like-new CD from its case and the MacBook ripped the whole thing successfully. It just appears that the drive is sensitive to the most minute scratches? Is that really an issue or do I need to get some kind of CD polisher?

Possibly, but it could be the drive. I mean, if it was that sensitive, surly by now other MB owners would have said something too? If I were you, I'd want it checked out.

 

[jesusphreak]

Possibly, but it could be the drive. I mean, if it was that sensitive, surly by now other MB owners would have said something too? If I were you, I'd want it checked out.

Well it just now ripped a different CD with a decent amount of scratching without problems. How long is my initial warranty or whatever that allows me to bring it in? And can I always call Apple support for free or is there a time limit on that?