Comments

johnmeyer wrote on 12/27/2013, 1:54 PM
BTW, did I mention that you'd probably be happier with a program that could split captured HDV tapes and preserve the metadata? lol :-DYes, about three times, I think. :) Can you (or anyone else) suggest such a program?

I am definitely not a person who thinks Vegas must do everything, and would be more than happy to do my "cuts-only" edits in something else and then, once I have my "keepers," I would then import that material to Vegas for creating my next masterpiece.

farss wrote on 12/27/2013, 3:04 PM
JM said : [I]"Can you (or anyone else) suggest such a program?"[/I]

I don't know if it would be directly applicable to what you want to do however I'd look into Avid's systems.

I'm somewhat surprised that some here question the usefulness of all this metadata stuff. They might want to think about reference files. My understanding is that several NLEs are capable of producing a rendered output that contains all the data required to rebuild the video from the original source. I see that as very convenient.

What would meet you needs is using two Sony HDV VCRs but you need to choose them carefully as the cheaper HDV VCRs are not capable of making assemble edits with intact metadata.

Bob.
Rob Franks wrote on 12/27/2013, 3:10 PM
"Indeed. Is it possible that John was of the opinion that that info would be included in the render of a SMART render?"

Well, first of all whether or not it's a "smart render" or a dumb one makes no difference. It's still a RENDER (not a copy) so it's a completely different file.

Secondly a "smart render" doesn't necessarily mean nothing has changed. Let's say you throw in a single crossfade somewhere. Now what do you call it? An almost smart render? A mostly smart render? No. Sorry. AGAIN it;'s a completely new file.
JohnnyRoy wrote on 12/27/2013, 3:35 PM
> "Can you (or anyone else) suggest such a program? "

Good ole' Womble still works with HD MPEG2 streams. It can cut parts of of an M2T file without rendering. I'm not sure how much metadata it preserves but there is a trial that you could test with. I bought this a long time ago and it has gotten me out of a few last minute MPEG2 DVD render jams.

~jr
Rob Franks wrote on 12/27/2013, 4:40 PM
"It absolutely could for one of the files. So, for example, if I was rendering to HDV and I placed two events from a Canon 7D and two events from my Sony Z1U HDV camera on the timeline, Vegas Pro would happily smart render the event containing the HDV data, copying the video from the source media into the target file along with rendering the events from the 7D. Smart render will always work for the events containing media formats that it supports regardless of what else is on the timeline as long as there are no FX, cropping, compositing, etc. on those events. My scenario is valid and is the reason that smart render has no bearing on the metadata contained in the new file.."

Bloody good example!
Another one on the same base..... two events with different times get smart rendered. What time should metadata read? (Actually I see you used that example above. Sorry all.... just got back from work and playing catchup here)
Rob Franks wrote on 12/27/2013, 5:05 PM
"I suppose Vegas could detect the special case when only one media clip exists and preserve metadata in that situation."

But that's not the objective of a Non Linear Editor. The entire basis of an NLE is to preserve the original file while creating (not copying) another.... and "smart rendering" has nothing to do with "copying".
farss wrote on 12/27/2013, 5:21 PM
Good grief, do you understand what "preserve source timecode" is for in most other NLEs?
That feature was even recently added to After Effects.

The fact that Vegas has never been able to do any of this is why it's laughed at by the professionals. Most broadcasters will ask for tapes with program starting at a specified timecode yet Vegas cannot even do this!
Preserving timecode and metadata is just a given in most editing systems.

Bob.
johnmeyer wrote on 12/27/2013, 6:35 PM
Good ole' Womble still works with HD MPEG2 streams.It does? I own it and never realized that. I'll report back later whether it works.

Here's one back at you: did you know you can do your actual edits in Vegas and then have Womble do the actual cuts? There is a little utility that Womble created which can take a text EDL from Vegas and then create a Womble project. It is pretty limited and a little gimpy in spots, but it does work and lets you get the best of both products.

As for some of the negative comments about preserving metadata I really don't get where the negativity is coming from. Believe me, I really do understand the definition of smart rendering. Here is that definition:

Smart Rerndering Definition. The original video pixels are identical in the rendered file to what they were in the original file, but only on those portions of the video where no change has been made and only where the cuts are done on GOP boundaries. If even one pixel needs to be changed for any frame, or if a portion of the timeline contains a source that doesn't match the output spec, then those frames must be re-rendered, resulting in a recompression and loss of video quality for that portion of the new rendered file.

There is no technical reason why metadata has to be stripped (and it could even be passed through for those portions of the render which are NOT smart rendered). As Bob points out, lots of NLEs don't remove the metadata, and many make very clever use of the information.

There is absolutely no way that removing the data can be promoted as a feature because if you don't need the data, you can simply choose to ignore it and your final production will be not be compromised in any way. However, if you need any portion of that metadata and it has been removed, you have a lot of work ahead of you to recreate it and save it with your work.


johnmeyer wrote on 12/27/2013, 7:02 PM
Re: Womble

Good news/bad news.

Good news: I used Vegas to creat the text EDL, and then used the Womble utility to convert that text file to Womble project format. I then opened the resulting project in Womble and confirmed that the cuts I made in Vegas were intact. I then exported from Womble to a single HDV m2t file. It took only a short time and Womble "smart rendered" the result in a few seconds, pausing briefly to re-render at most of the cut points (because they were not on GOP boundaries).

This may sound a little complicated, but it took less than one minute to do, and then another few minutes waiting for the copy, ah, "smart render" to take place.

Bad news: Vegas refused to "print to tape" using the Womble-created file. This file plays just fine and Vegas is happy to read it and play it. It just won't print it back to tape and claims it is an unsupported format. I tried three different versions of Vegas and got the same behavior.

So, does anyone have a recommendation for a program or utility that they use to print HDV back to tape? I know that HDV Split captures, but I don't think it prints. The old SCLive (Scenalyzer) prints DV to tape, but not HDV.

Without printing to tape, I can't confirm if the metadata has been preserved.

[edit]I downloaded this utility:

HDVdataMon

and looked first at the metadata in my original HDV files. I was able to watch the original time (not timecode, but time of day) change frame-by-frame, and also watch the exposure information. So, the utility seems to work. I then loaded the the file created by Womble. Bummer: it too hoses the metadata.
wwaag wrote on 12/27/2013, 7:30 PM
Suggest you download DVMpro5. There is a 14 day demo. You can play your HDV files and it will show the metadata for a few seconds at least--then it quits since its a demo. Just tried it on an HDV file from an HC1 and it does work.

wwaag

AKA the HappyOtter at https://tools4vegas.com/. System 1: Intel i7-8700k with HD 630 graphics plus an Nvidia RTX4070 graphics card. System 2: Intel i7-3770k with HD 4000 graphics plus an AMD RX550 graphics card. System 3: Laptop. Dell Inspiron Plus 16. Intel i7-11800H, Intel Graphics. Current cameras include Panasonic FZ2500, GoPro Hero11 and Hero8 Black plus a myriad of smartPhone, pocket cameras, video cameras and film cameras going back to the original Nikon S.

videoITguy wrote on 12/27/2013, 7:51 PM
As I have suggested near the beginning of this thread, and many other data/timecode issue threads - I highly recommend a user of VegasPro invest in DVMPro5 from the UK. It will become the utility of choice just like Gary's Timeline Tools, or Vasst Ultimate are indisputable work tools for the VegasPro user.

This entire thread could have been a lot shorter.
PeterDuke wrote on 12/27/2013, 9:31 PM
Nobody has commented on my post in which I point out that mediainfo reports a so-called menu stream in a HDV file. While absolute time could be computed from a creation date/time stored in a header and relative time while playing, I think it more likely that it is stored in this stream. This is reinforced by the fact that the f: number displayed in DVMPro can change while viewing a pan shot. How else could this happen except from info stored in a stream, and what more likely than the mysterious menu stream?

I changed the file end from m2t to ts and read the file into tsmuxer. It complained about an unknown stream. I then outputted to another ts file.

DVMPro played the HDV file renamed as ts exactly the same as the original, but gave an error message on the new ts file as follows:

Unrecognised format
johnmeyer wrote on 12/27/2013, 9:40 PM
The free utility I linked to in my last post (HDVdataMon) displays the metadata in real time, just like the shareware DVMPro. However, does DVMPro provide any editing capability? If not, the free utility seems to do what I need in order to test for the presence of metadata. I don't want to create a workflow where I export the code data to a text file, which DVMPro can do, but the free utility cannot. Exporting the code data is a last resort.

So, I don't yet have a solution, although I sure managed to create a lively thread. That wasn't my intent.

I actually don't think a solution to my original problem exists outside of the $$$ programs Bob ("farss") mentioned. For less money, it is possible that Pinnacle Studio may do what I want. Haven't used it in a decade, but maybe I should try it out again. For me, that would be coming full circle, since I started editing with that over a dozen years ago.

PeterDuke wrote on 12/27/2013, 9:49 PM
What makes you think Studio will do it? Would it have to be the latest version? I have version 16 but never installed it.
johnmeyer wrote on 12/27/2013, 9:51 PM
What makes you think Studio will do it?I've been doing research outside this forum, and it was mentioned in several threads. However, I haven't yet read a post that I would consider both credible and definitive.
PeterDuke wrote on 12/27/2013, 10:14 PM
John

The preamble on the web page you gave says that HDVDataMon should only be used with PAL/25fps. I presume that you are NTSC/29.XXfps. Have you checked that out?
johnmeyer wrote on 12/27/2013, 10:19 PM
The preamble on the web page you gave says that HDVDataMon should only be used with PAL/25fps. I presume that you are NTSC/29.XXfps. Have you checked that out?I did not see that. However, it worked well enough for me to see the data and watch it change in real time. That was all I really needed in order to tell whether the data was there or not.

BTW, I agree with the point you made in an earlier post that the data is stored in the stream and not the header. I was 99.99% certain this was the case, and said so in one of my first posts, but after watching the exposure data change as the camera panned past some windows, it was quite obvious that the data is stored at least with every GOP, and possibly with every frame.
Rob Franks wrote on 12/27/2013, 10:58 PM
"That feature was even recently added to After Effects."

Well Bob, If preserving timecode was "RECENTLY" added to After effects then I guess AE was laughed at by the pros until just "recently" too, right ;)

"Preserve timecode" is an issue of timing in relation to itself, nothing more. It's not like preserving time of day or date or camera settings.
Rob Franks wrote on 12/27/2013, 11:21 PM
"Smart Rerndering Definition. The original video pixels are identical in the rendered file to what they were in the original file, but only on those portions of the video where no change has been made and only where the cuts are done on GOP boundaries. If even one pixel needs to be changed for any frame, or if a portion of the timeline contains a source that doesn't match the output spec, then those frames must be re-rendered, resulting in a recompression and loss of video quality for that portion of the new rendered file."

Ummm... not really.

Not sure where you got an actual definition from because I'm not even sure there is an official term called "smart rendering" (which is why Vegas calls it "no re compress" rendering. As far as I know, the term "Smart render" was originally born under the Ulead flag, which of course doesn't exist anymore. But there seems to be a few definitions out there which differ a little here and there. The one I believe which fits best is this:

"Smart Rendering is an


The reason why I like this definition is that it makes it crystal clear that EDITING can and does take place even when it's not happening at the pixel level. In other words, it is NOT a copy.

Smart rendering is not about copying and/or not changing. It's about editing/rewriting with minimum damage to the quality of the video.

But regardless to any of that, there is no real way of verifying that no change has taken place after a "smart render" In fact you sort of proved it with your Womble "smart render" not printing back to tape.
There is also another active thread on this board right now asking why a "smart rendered" file has a different size than the original. This clearly proves that "copying" is not taking place. The encoder is indeed doing some calculating and rewriting. Now, are we looking at error, or null data, or something else is anybody's guess, but if it is not being COPIED then how can you possibly say that is anything other than an original and unique file worthy of its own unique metadata?

I stand by my original statement.... once the file has been scrutinized and rewritten by another encoder it is no longer an identical representation of the original. It is a unique and different file altogether and is not worthy of the original metadata

"As for some of the negative comments about preserving metadata I really don't get where the negativity is coming from"
Passing original metadata to a copied file is expected, but passing original metadata to file which has been rewritten by another encoder is quite useless.

An interesting note which may or may not be related. It appears the new Sony avchd cameras are not allowing original metadata to be passed on even when the clips are dragged (copied) from the cam to the hard drive. With my Sony SR11 I could drag my clips to my hard drive and the original time/date of the clip would show up in windows explorer. My new PJ790 no longer allows that. If I drag the clip off then Windows reports a new "original" date (the date and time I dragged it off) Vegas also sees the "original" date as being the date and time dragged.
john_dennis wrote on 12/27/2013, 11:36 PM
Sony refers to the process with the term, try page 406, 515 and 580 in the Vegas 12-670 User Manual.
farss wrote on 12/27/2013, 11:44 PM
[I]"
Well Bob, If preserving timecode was "RECENTLY" added to After effects then I guess AE was laughed at by the pros until just "recently" too, right ;)"[/I]

Um, not really. It's a compositor, not a NLE however at times people do use it to process video. I guess enough people asked Adobe for it and Adobe listened.

[I]"
"Preserve timecode" is an issue of timing in relation to itself, nothing more. It's not like preserving time of day or date or camera settings"[/I]

Wrong. Timecode is generated by the camera or an external timecode generator.
Timecode may in fact be time of day, record run or free run. Each frame of video has a block of data that carries amongst other things the timecode for that frame. Audio gear can also record timecode. I believe Vegas the ability to read timecode from BWF audio files and sync them to vision. Last time I checked it had a problem writing valid BWF files but that's another issue.

The more relevant issue is that Vegas cannot print to tape with TC starting at anything other than 00:00:00;00. Given that one would normally prepare a tape with a slate then T&B then black this make it impossible to create a tape with program starting at an hour tick.

Bob.

Rob Franks wrote on 12/27/2013, 11:45 PM
Page 406 uses "smart rendering" in brackets so it is not an official term. Sony's official term is "no recompress rendering"

It also does not define the term.
Rob Franks wrote on 12/27/2013, 11:48 PM
"Timecode may in fact be time of day,"
So then let's go back up to the above example. If I smartrender 2 clips each with different Times, which time is the correct one which should be carried over with which metadata?
Rob Franks wrote on 12/27/2013, 11:59 PM
"Um, not really. It's a compositor, not a NLE "
So then why are you comparing a compositor to a NLE??? It seemed not to be too much different to you a few moments ago when you brought it up.