No fldave I'm rendering out a .m2t HDV file first and then just printing it to tape. Every time I do a 40-60 minute project I get glitches. Last night I did one and got glitches at 11 and 17 minutes in a 52-minute project. Previously I had glitches at around 25 and 43 minutes in a 60 minute project. The video just hangs on one frame for a second or so before continuing.

OK, regardless of cost, does any NLE make a robust job of this?

interested too.

had awful problem ptt to m15 with m2t's. finally got it to work by turning OFF no-recompress when writing final edit to archive.

haven't tried it since the new mpg.dll - that might have made a change (or possibly not).

nh, are you doing no-recomp?

are you using the new .dll?

leslie

Nick,

Although I don't have Vegas 8 pro, I have read about red frames and black frames that appear and disappear with that software. Have you checked for those? Someone posted a workaround that involved capturing directly to .m2t on the hard drive, editing, then loading it into Vegas 6 to avoid the odd frames. They said it worked every time.

Another thought is the firewire itself. Do you have a card or a built-in firewire port. And which chipset? Is it a TI chipset? Can you try a different port?

John

It sounds to me like your computer may be going off to do something in the background causing the transfer to pause. Streaming HDV off to tape only requires a transfer rate of around 3.75 megabytes per second, any machine should be able to do this without breaking a sweat. Check for background processes, like anti-virus software.

Something more basic to check. The transport in the camera.

Then again I recently rendered a XDCAM EX project to WMV and there was a 1 second frozen frame sequence near the end of the WMV. There's no way that can be because of another process stealing CPU cycles, the source plays out perfectly on the T/L.

Like Nick I find this embarassing when the client sees it.

Bob.

Thanks for the help guys.

ushere, I'm using no-recomp but I'd be surprised if that had an effect on the "Print video to HDV tape" command which deals with a file that's already rendered.

I am using the new .dll but I had identical problems using the old .dll too.

craftech, I have checked the rendered .m2t file for problems and I cannot see any at the points that the tape stutters.

I am using the Dell laptop's built-in IEEE-1394 port.

John_Cline, I do disable everything I can when I print to tape, including virus scanning software.

I suppose there might still be something else running that might be causing the glitches.

I know this is an over-simplifaction but I just wish Vegas would basically "take over" my computer during the print-to-tape process, or make itself a bigger buffer/cache in the same way that DVD-burning software does.

As Bob says it is embarrassing, especially as I have to make excuses for the glitches before I show the film and assure potential customers that the glitches won't be on their DVDs.

Is anyone getting reliable prinitng to tape with HDV in Vegas?

hi nick,

[ushere, I'm using no-recomp but I'd be surprised if that had an effect on the "Print video to HDV tape" command which deals with a file that's already rendered.]

what i meant was i turn no-recomp OFF when preparing a file for ptt. i find if i make a 'master' file for ptt if i prepare it with no-recomp ON i always had problems with glitches. with it turned no-recomp off the file produced usually printed ok.

don't know the reasons, but there was a thread i took part in quite some time ago about it....

good luck

leslie

>>...turn no-recomp OFF when preparing a file for ptt... <<

That is strange and it's not something I ideally want to do as I have very limited time to render my master files and I want to retain as much quality as I can.

IF I get a particularly bad print and I start over, I notice that the glitches are in different places. So it doesn't seem like localised errors in the m2t file are causing the glitches.

I fixed a couple of short troublesome .m2t files using MPEG2REPAIR and I'm wondering if running the master .m2t through that might help. When I fixed my short files MPEG2REPAIR gave no reports of having fixed errors but the files played nicely in 8.0c after I had done it.

Anyway, for the time being I'm still getting 3 or 4 infuriating glitches during a 50-minute ptt.

Any other experiences with HDV print-to tape? Is anyone getting reliable long prints? Anyway having reliabilty with any other software?

Try turning off your screen saver.

I used to get these A/V stalls when writing to tape (DV).

Maybe will work for you, too?

Greg

Screen saver was already set to "none".

I have got the 3Gb switch set. Could that be the problem?

>>...turn no-recomp OFF when preparing a file for ptt... <<

"That is strange and it's not something I ideally want to do as I have very limited time to render my master files and I want to retain as much quality as I can."

there was quite an extensive thraed i started about this ages ago...

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=592435

back then i found i had NO problems with no-recomp turned off. with the updated mpeg.dll my problematic clips (i had two of them worked happily), but i haven't ptt'd since then (ie. on 8d / 8c) as most of my programs are short enough to b/k to disk. longer programs i have now started b/k to ex hd's and am waiting for ALL ptt to be sorted (ha!), before wasting time trying with anything over 40mins....

leslie

Reading one of the whitepapers in the knowledgebase reveals that SCS are saying that files written with No Recompress On cannot be written to tape. The reason is fairly simple. HDV on tape has a fixed length GOP, edit a file and render with No Recompress and it's almost certain you'll create a GOP of a different length.

Now there should be a way to avoid this, only edit on GOP boundaries. If all you want to do is put stock footage onto tape or trim off crud for archiving back to tape that should be just fine. Only thing we need is for Vegas to display I frame markers. DVDA can do this, why can't Vegas?

Bob.

Well, I'm going senile. I even replied to that earlier thread and apparently even tested it myself as recently as May! *blushes*

So for the tape that I use to play back over component cable to our Epson 720p projector for my show I'll use "no recompress" OFF. But for my archives I'll probably encode a 2nd version with "no recompress" ON to maintain maximum quality.

It is however weird that the glitches come in different parts of the video when the SAME smart-rendered m2t is printed to tape. I would have thought the glitches would be repeatable.

Anyway thanks for the help guys. I'll report back if this doesn't fix my problem.

in passing....

i do stuff for broadcast, and after 30+ years in it, i have yet to meet anyone who can look at well shot hdv and tell me "oh, that was rendered without smart rendering". what loss there is i think disturbs us mentally more than the actual loss itself.

leslie

You're probably right. I'll let you know in 5 days' time, although the projector is downrezzing to 720p so it will be hard to tell.

Of more concern to me is how much longer the rendering time might be without smart rendering.

hi nick,

in general, i do doco's, so other than a bit of cc and titling....

if i remember (i usually leave things to render on their own - big - overnight, little, during lunch or the evening), without no-recomp i think it was slightly over double prog lenght. but your mileage might vary....

good luck

leslie

I've done a couple of 50-60 minute projects now with "no-recompression" off and the render time is a bit longer but not much. However I'm still getting the glitches when I play the tape.

On the first project there were 3 glitches around the 11 minute mark, and on the other there was 1 glitch somewhere around 10 minutes and another somewhere around 40 minutes.

Slightly fewer glitches than when I had "no recompress" ON but still glitches nontheless.

I guess I'll revisit every single process that is running while I write to tape and see if there are any more I can disable.