Capturing Tapes to ProRes vs DV

[jagabo]

If you want some analysis of what's going on upload a short sample of the avi file captured with VirtualDub and the resulting mp4 file from handbrake. Especially helpful are colorful shots with moderate motion and still shots with sharp vertical edges.

Regarding the aspect ratio -- the 720x480 huffyuv avi doesn't include aspect ratio information. It's up to you to tell the editor/encoder the source is 4:3, not 3:2.

[Christina]

Ozymango - I didn't experience the same audio drift with the USB/Windows/AVI file but to me it just looked a little "off" the entire way through. When I finally capture with the DAC200 that's when I'd be really curious to know if a straight conversion with handbrake creates the drift issue (which as a reminder, I was able to fix in the camcorder passthrough dv captures by encoding the video separate in handbrake and the audio in Quicktime, and then putting them back together with ffmpeg).

Jagabo - As soon as I have time, which may not be til next week, I can do that and show everyone what I'm talking about.

Both of you - regarding aspect ratio, further reading/research is required on my end to understand what exactly is happening here and which is better/worse, although I'm sure someone on this thread will probably chime in... Since I left everything @ default/same as source etc when encoding in handbrake, I assume "standard" DV capture is at 720 and the Huffyuv/Vdub "standard" capture is 640, but that is an assumption on my part and I don't have access to the source files right now to look. I also remember seeing something in handbrake reference an aspect ratio and a "stored as", so definitely more info is needed on this part!

[TimA-C]

by the time you've finished tweaking and filtering and re-encoding you'll probably be sick of the video and the audio anyway . . . !

This is so true. After a hobby project is done, I often won't watch it for a year. I just can't enjoy it yet. I'm still in "detect flaws" mode, and not entertainment mode.

So true!

[jagabo]

The ITU standard for capturing analog NTSC video is 704x480, regardless of whether the content is 4:3 or 16:9 Display Aspect Ratio (DAR). Typically, an extra 8 pixels is captured to the left and right of the frame to bring that up to 720x480 (in case the source or capture is slightly off center). DV, and almost all capture devices, follow this standard.

Some containers and codecs include aspect ratio information, some do not. DV/AVI does, huffyuv/AVI does not. So even though both follow the same standard programs usually display DV properly (4:3 DAR), huffyuv, not (3:2 DAR).

[Christina]

Jagabo - Thank you. That actually makes sense to me, I think, although some things are still a little fuzzy.

Tell me if this is right- If not, just let me know and I'll go back to google. Don't want to open another can of worms here!

1. 720x480 is what I should be aiming for in my finished product, despite capture method. (DV should "just work", whereas huffyuv/avi, I will need to "tell" the editor/encoder to use 720x480)
2. Handbrake saw the HuffYUV/AVI file as 640x480 because the codec/container didn't specify the aspect ratio, so it "assumed" 3:2?? (Why?) Therefore the output mp4 was *actually* 640x480 and that's why my TV displayed it that way. (?)

What I am struggling to understand is how a video/VHS tape can be in one DAR (I guess it doesn't make sense to talk about VHS tape in terms of resolution but it certainly has a "correct" aspect ratio? What is it?) and be captured in a different DAR without the whole thing being distorted/stretched/squeezed. I'm more familiar with image resolutions, and I know that if I have a 720x480 file, and I then resize it to 640x480, it's going to be squashed, or vice versa, stretched. Is video the same concept or is it different because of lines/interlacing and such..?

To ask that question in another way, regarding a VHS capture in the above 2 methods, if someone's face is taking up nearly the whole screen, is their face going to look as it does in "real life" in the 720x480 file AND the 640x480? Or is it going to look "skinnier" in the 640 and "correct" in the 720? Or "fat" in the 720, and "correct" in the 640? (I hope at least one person is having a good laugh at me at this point.)

[Christina]

I found this in an older thread posted by LordSmurf which sort of helped clear a few things up for me... as Ozymango would say, clear as mud! It is a lot to digest being new to all of it.

(LordSmurf hope you don't mind if I quote you here. I'm putting this here for myself to come back and reference later or anyone else who may stumble upon this thread in the future.)

AR = aspect ratio
SAR = storage aspect ratio
DAR = display aspect ratio

720x480 is SAR for NTSC
The 720x480 pixels are not square, but rectangle. On display, the DAR is 4:3.

AVI has no AR flag, is 1:1 square. But AVI is also not a watching format, only capture/edit/restore. For watching, the make a later copy as MPEG with flags for SAR/DAR, or convert to 1x1 square aspect H.264 as MP4/MKV.

Capturing to 640x480 is often not ideal, because you lose some of the needed data. To convert VHS to streaming, you must properly deinterlace, change aspect ratio, and either mask or crop the overscan.

[jagabo]

1. 720x480 is what I should be aiming for in my finished product, despite capture method. (DV should "just work", whereas huffyuv/avi, I will need to "tell" the editor/encoder to use 720x480)

Your capture resolution should be 720x480 or 704x480. If your making a DVD then the finished product should also be one of those dimensions. But if you are making a video to upload to Youtube you want to resize to a 4:3 frame size like 640x480 or 1440x1080.

2. Handbrake saw the HuffYUV/AVI file as 640x480 because the codec/container didn't specify the aspect ratio, so it "assumed" 3:2?? (Why?) Therefore the output mp4 was *actually* 640x480 and that's why my TV displayed it that way. (?)

In my experience Handbrake sees a 720x480 huffyuv AVI as 3:2 DAR. That's because the AVI file has no aspect ratio information other than the frame dimensions. It will encode at 720x480 and assume square pixels. Players will display that as 3:2 DAR.

DV AVI has aspect ratio information within the DV data. Handbrake sees that and encodes 4:3 DAR. If you elect to use Anamorphic (non-square pixels) encoding it will leave the frame at 720x480 (it may crop away black borders) and flag the video as 4:3 DAR. A player that follows the AR flag will automatically scale the 3:2 frame to a 4:3 size for display: 320x240, 640x480, 960x720, 1440x1080... If you elect to use square pixel encoding it will resize the frame to 640x480 and flag it as square pixel.

What I am struggling to understand is how a video/VHS tape can be in one DAR (I guess it doesn't make sense to talk about VHS tape in terms of resolution but it certainly has a "correct" aspect ratio? What is it?)

4:3

and be captured in a different DAR without the whole thing being distorted/stretched/squeezed.

Vertically an analog NTSC signal consists of 525 scan lines, 485 of which contain picture information. Modern capture devices only capture 480 of them. Horizontally, each scan line is a continuous waveform that can be captured with as many samples (pixels) as you want. Modern devices capture using 720 samples (pixels), 704 of which constitute the 4:3 DAR of the 480 pixel height.

I'm more familiar with image resolutions, and I know that if I have a 720x480 file, and I then resize it to 640x480, it's going to be squashed, or vice versa, stretched. Is video the same concept or is it different because of lines/interlacing and such..?

It's exactly the same with video. The captured 720x480 (704x480) frame needs to be squished back to 640x480 for proper display.

Here's an example from a 4:3 DV camcorder. The full 720x480 frame looks like:

[Attachment 48624 - Click to enlarge]

The 4:3 image is contained in a 704x480 portion of that frame. So we crop 8 pixels off the left, 8 pixels of the right, leaving a 704x480 frame:

[Attachment 48625 - Click to enlarge]

Now we resize from 704x480 to 640x480 to give a 4:3 frame:

[Attachment 48626 - Click to enlarge]

Let's verify that the bowl is a perfect circle. We further crop so that the frame just touches the edges of the bowl:

[Attachment 48627 - Click to enlarge]

That leaves a 402x402 image, a perfect square surrounding a perfect circle. We have now verified that the correct DAR is 4:3 and that comes from a 704x480 portion of the original 720x480 frame.

[dellsam34]

Christina are you sure you are capturing at 720x480 in Vdub?

[Christina]

Christina are you sure you are capturing at 720x480 in Vdub?

No not the least bit sure at all, but I don’t think I said that I did either. It was my first time using VirtualDub so I’ll go back and look more in depth at the settings. I was just happy to get HuffYUV working along with my audio - didn’t get much further than that with the settings.

[Christina]

Your capture resolution should be...

Thank you for such a detailed explanation. I’m finding this topic a little challenging to wrap my head around but that definitely helped.

My final destination for my files is an external hard drive to be played on a tv (either directly through USB if the TV has that or through some type of media player if not). This (playing on tv) is where I first noticed that one of my test videos was wider on the screen than the other. Prior to all of this, I didn’t know what anamorphic even meant. I didn’t know a pixel could be anything but square. I didn’t realize a video could be stored at one aspect ratio and played back as another.

[head explodes]

[TimA-C]

To quote Master Obi-Wan, "You've just taken your first step into a larger world." (Or, following ozymango down the rabbit hole, I guess I could quote Mr Morpheus and say, "Welcome to the real world.")

[Christina]

If you are making a DVD, for example, from a VHS capture and keep things at 720x480, how do you get things back to real proportions? (i.e. how do you get your plate back to a perfect circle if you’re not displaying at 640x480?)

[jagabo]

If you are making a DVD, for example, from a VHS capture and keep things at 720x480, how do you get things back to real proportions? (i.e. how do you get your plate back to a perfect circle if you’re not displaying at 640x480?)

You specify the DAR flag when you encode. For example, in HCGui:


[Attachment 48629 - Click to enlarge]

[Cornucopia]

I'm gonna rock the boat a little: it's best to get this cleared up and understood properly at the onset rather than have conflicting thinking muddling up what might otherwise be decisive workflow.

Aspect Ratio *could* be a ratio of any 2 different aspects (dimensions), and as such, it would include the dimensions of the whole display/frame ("DAR" or "FAR", respectively), the dimensions - whether actual or theoretical - of the individual pixel/sample themselves ("PAR" or "SAR"), or as is commonly discussed here and elsewhere on the net, the dimensions of the stored pixels in the file ("SAR"). Except it isn't. Not that loosely, certainly.

Because while the first 2 examples actually are exhibited DIRECTLY in files (stored) and streams (live) - the numbers involved ("4:3" or 1.3333, "16:9" or 1.7777, etc) in describing these ARs, when used and accommodated for, are stored in those number forms as flags of some sort - the last one is only ever a derived number that is (presumably) used as shorthand to "ease" the understanding and calculation of formulae involved in working with imaging. Unfortunately, that easy shorthand has ended up making things more complicated and side-tracking the calculations. Not only that, but then you have duplication and conflict of abbreviations.

So...

please try to think of the master formula NOT as

DAR = PAR * SAR

, sometimes written as

FAR = SAR * StorageAR

but instead, think of it as

DAR = PAR * W / H

.

This uses "Width" and "Height" directly, rather than as a ratio. Why? Because there is NEVER a time when any media file or stream has that RATIO stored (or transmitted). It doesn't exist on its own. There is never a "storage AR" flag anywhere anytime. And if you ever are attempting to do resize/scaling calculations with this formula, working directly with the dimensions themselves actually helps you, whereas working merely with the storage AR actually hinders you.

Example for resizing:
If you know the DAR and PAR of both your source file and your target file, and you know the dimensions of your source file and you want to know the dimensions of your target file, using my suggested formula will give you that quickly and clearly and exactly. If you started with only the "shortcut/easy" version and did NOT know the raw dimensions of the source file but only the StorageAR, well yes, you will know the StorageAR of the target, but if the intent is to resize, you will NEVER know the actual dimensions for it based on that shorthand version. And there are a million combinations of actual dimensions whose Storage AR equates to what gets calculated.

Actual working example:
720 x 480 image (so 3:2 Storage AR), but 4:3 DAR, so PAR=8:9 - won't get into the complication of 704ITU adjustments right now.
You want to upsize it to HD (which is almost always square pixelled). Let's say a 720p type image.
DAR=PAR*StrgAR on both, so you know 1.333 = .8888 * 1.5 on the one side and 1.333 = 1 * 1.333 on the other side. What's the new size?

But if you use the actual dimensions, you can plug all the numbers into the formula, swap in the equivalencies in the other instance of the formula and solve for the unknown.

1.333 = .8888 * 720 / 480 and 1.333 = 1 * ? / 720

put another way
.8888 * 720 / 480 = 1 * ? / 720


or
? = .8888 * 720 / 480 * 720 / 1
= 960

and 960x720 = 4:3 DAR as you would expect it to turn out to be!


A few other things to think about:
modern displays (LCD, Plasma, LED, OLED) can be considered to ALL have a 1:1 or "square" PAR (there are a few rare exceptions but you don't have to worry about them). Always keep this in the back of your mind when you are referring to what is being displayed, even as a screenshot or preview.

If you are dealing with Analog (and by virtue of our timeline, nearly all of that is SD material), nearly ALL of that is non-square (non 1:1) PAR, so anytime you are dealing with capturing, you would have to take into account conversion between non-square and square PARs. This conversion should, for quality's sake, only happen ONCE. Sometimes it should happen at the A/D capture stage, sometimes at the very end IN THE DISPLAY. Occasionally, if you are incorporating multiple sources, you will have to do more than one conversion, or do the one conversion in the middle of the workflow.

As concerns file formats, it has been mentioned - some formats are able to store either DAR or PAR flags in their codec stream or in their container, others are not. So a DV avi has a DAR flag while a HuffYUV avi cannot. Because the AVI container doesn't have a true facility for storing DAR, only the raw dimensions (unless you count proprietary/private extensions). The DV codec has that flag, the HuffYUV doesn't.
However, an H.264 MP4 is an example of a file that has facility for DAR flag in both the codec and the container (which occasionally can get one into trouble if they are in conflict).

You seem to be familiar with Picture formats. Most of those ASSUME a 1:1 PAR, unless told differently. BTW, Photoshop didn't have the ability to specify DAR until after v8.0 (the first CS), IIRC. Since then, PSD files may have non-square pixels, or not. Unless those are designed specifically for video, those non-square ones are a rarity, though.

Lastly, IMO some programs are DUMB, or at least sloppily coded. Some use that "easy/shortcut" in their calculations, and that gets YOU into trouble unless you are aware of and can account for their bias.

Now that you know this, you will be better armored and able to control what you intend to get as a result.

Scott

<edit>BTW, my comments do not necessarily negate any of the helpful suggestions put forth by other members here. Zero shade to jagabo, TimA-C, etc. One of the goals of VH is to help and that means to spread the knowledge around.</edit>

[dellsam34]

If you capture your AVI in 720x480 and convert to mp4 with proper flag for 4:3 it should look like this in MediaInfo:

General
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 1.65 MiB
Duration : 9 s 431 ms
Overall bit rate : 1 466 kb/s
Writing application : Lavf58.20.100

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3
Format settings : CABAC / 4 Ref Frames
Format settings, CABAC : Yes
Format settings, RefFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 9 s 410 ms
Bit rate : 1 267 kb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.122
Stream size : 1.42 MiB (86%)
Writing library : x264 core 157 r2935 545de2f
Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box : avcC

Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 9 s 431 ms
Duration_LastFrame : -20 ms
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 46.875 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 222 KiB (13%)
Default : Yes
Alternate group : 1

The original lossless file looks like this:

General
Format : AVI
Format/Info : Audio Video Interleave
File size : 191 MiB
Duration : 9 s 409 ms
Overall bit rate : 170 Mb/s
Writing library : VirtualDub build 35491/release

Video
ID : 0
Format : YUV
Codec ID : UYVY
Codec ID/Info : Uncompressed 16bpp. YUV 4:2:2 (Y sample at every pixel, U and V sampled at every second pixel horizontally on each line). A macropixel contains 2 pixels in 1 u_int32.
Duration : 9 s 409 ms
Bit rate : 168 Mb/s
Width : 720 pixels
Height : 480 pixels
Display aspect ratio : 3:2
Frame rate : 29.970 (30000/1001) FPS
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Compression mode : Lossless
Bits/(Pixel*Frame) : 16.000
Stream size : 188 MiB (99%)

Audio
ID : 1
Format : PCM
Format settings : Little / Signed
Codec ID : 00000001-0000-0010-8000-00AA00389B71
Duration : 9 s 409 ms
Bit rate mode : Constant
Bit rate : 2 304 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Bit depth : 24 bits
Stream size : 2.58 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 37 ms (1.11 video frame)
Interleave, preload duration : 1000 ms

[Cornucopia]

See that "Display Aspect Ratio" on the 2nd item? That is MediaInfo getting the correct but incomplete info and then giving out the wrong nomenclature/result.
It's doing this because it is making assumptions. It is very good software, but is flawed in certain areas. This is one of those. (I've asked as a feature request that they make clear just where they get the info for their fields - codec or container, which flag, where in the structure, and whether it's directly read/decoded or if calculated - but they have not implemented this).
Neither the PAR nor the DAR is specified in AVI with YUYV, so it is deriving it's "DAR" from the calculation of the dimensions, AND assuming it ought to have a 1:1 PAR, so then it SHOULD be 3:2 if the assumption were to be correct. Very likely, it should NOT be square pixelled, but 8:9, 10/11 or similar, giving it's true DAR of 4:3. They could just as easily and more accurately have said "undefined" or "N/A" or maybe "3:2 - (calculated with 1:1 PAR assumed)".

Scott

[lordsmurf]

But if you use the actual dimensions, you can plug all the numbers into the formula, swap in the equivalencies in the other instance of the formula and solve for the unknown.
1.333 = .8888 * 720 / 480 and 1.333 = 1 * ? / 720
put another way
.8888 * 720 / 480 = 1 * ? / 720
or
? = .8888 * 720 / 480 * 720 / 1
= 960

Back in school, I'd have never guessed that I'd be using basic algebra for video.

(I've said this for many years now.)

[Cornucopia]

Yup, after graduating, I ended up having to re-learn Trig and learn on my own Analytic Geometry so I could properly code my psycho-acoustics app.
I've found stuff from lots of different disciplines has come in handy over the years. School was worth it.

Scott

[celsoac]

On a side note, does anyone know why the Quicktime ProRes capture would be ever so slightly sped up compared to the DV capture of the same footage? Over an hour tape, the ProRes version is about a minute shorter, give or take, and if I play the files simultaneously in sync, the DV captured footage starts to fall behind within a minute.

My guess for this is that DV keeps the VHS framerate, 29.97 frames per second in the NTSC system (I assume you're using this), while perhaps ProRes saves it at 30fps. Now, that issue can be overcome by editing the file header later, for example with Atom Inspector (freeware), or perhaps with Loosless Frame Rate Convertor (freeware). It at a loss, contact me (is there DM here?) and I'll give you the files.

It's good that you mention this issue about ProRes, because I also experimented with encoding with Quicktime ProRes today for the first time, and I will not do it now.

[Christina]

It's good that you mention this issue about ProRes, because I also experimented with encoding with Quicktime ProRes today for the first time, and I will not do it now.

I wouldn't rule it out based on my findings alone. Plenty of people use and are happy with ProRes so it just depends on what your needs are. I'm sure hardware and software also matter.

[Christina]

The DAR/SAR/PAR conversation is giving me a headache!

At least I understand now what the settings mean in Handbrake I was seeing all along regarding storage vs display because I had no idea before why there were two different ones or what I should be setting them to. I'm sure as I move along, the info you all have given me will become clearer as I put it into practice.

Thanks again for all the help. I've got another topic to get a headache about now... IRE.

[celsoac]

Jagabo - Thank you. That actually makes sense to me, I think, although some things are still a little fuzzy.

Tell me if this is right- If not, just let me know and I'll go back to google. Don't want to open another can of worms here!

1. 720x480 is what I should be aiming for in my finished product, despite capture method. (DV should "just work", whereas huffyuv/avi, I will need to "tell" the editor/encoder to use 720x480)
2. Handbrake saw the HuffYUV/AVI file as 640x480 because the codec/container didn't specify the aspect ratio, so it "assumed" 3:2?? (Why?) Therefore the output mp4 was *actually* 640x480 and that's why my TV displayed it that way. (?)

What I am struggling to understand is how a video/VHS tape can be in one DAR (I guess it doesn't make sense to talk about VHS tape in terms of resolution but it certainly has a "correct" aspect ratio? What is it?) and be captured in a different DAR without the whole thing being distorted/stretched/squeezed. I'm more familiar with image resolutions, and I know that if I have a 720x480 file, and I then resize it to 640x480, it's going to be squashed, or vice versa, stretched. Is video the same concept or is it different because of lines/interlacing and such..?

To ask that question in another way, regarding a VHS capture in the above 2 methods, if someone's face is taking up nearly the whole screen, is their face going to look as it does in "real life" in the 720x480 file AND the 640x480? Or is it going to look "skinnier" in the 640 and "correct" in the 720? Or "fat" in the 720, and "correct" in the 640? (I hope at least one person is having a good laugh at me at this point.)

If I understand it correctly, the issue here is the relation between "real" encoded pixels and relative pixel size, or pixel ratio. A PAL tape, for example, can sample at 702 or 720 "real" encoded pixels (or even 352!), but either one has to be "stretched" to 768 pixels to keep the 4:3 ratio for 576 horizontal pixels/lines. So, yes, a 720x480 file AND a 640x480 file can both look exactly the same IF the respective pixel ratios are defined correctly. If you open an MP4 file with Subler, you'll see that, and you'll be able to adjust that. If you have an MP4 file that looks distorted, you don't need to reencode it, but to correct the pixel ratio values with Subler. Another app that gives you this information (but you can't change) is VideoSpec.

So, when converting from MOV to MP4 it is not always necessary to change resolution. You can keep the original resolution and change pixel ratio later. Notice that different viewers may behave differently if pixel ratios are not entered appropriately (in Subler, for example). One app may show the correct proportions, another one may not. You have to enter both absolute pixel values (height and length) and pixel ratio, which sometimes you have to calculate.

[celsoac]

It's good that you mention this issue about ProRes, because I also experimented with encoding with Quicktime ProRes today for the first time, and I will not do it now.

I wouldn't rule it out based on my findings alone. Plenty of people use and are happy with ProRes so it just depends on what your needs are. I'm sure hardware and software also matter.

Thanks. Another problem I had with QuickTime ProRes is that I have to digitize very long tapes recorded from TV, while QuickTime stopped recording after a few minutes (buffer issue?). So, I am also using and OLD version of iMovie which outputs DV, as you do, which is the only one that does NOT break the recording due to out-of-sync or to dropped frames. Final Cut Pro X, which is great for editing, does not have a "manual" option to avoid those breaks. In my experience, DV encodes very well in Final Cut Pro. I also archive in DV and make viewable versions in MP4. I would NEVER encode directly into MP4 for any serious purpose. As to lossless encoding, I also did encoding to AVI with Pinnacle in Windows, but I haven't found any app/system in Mac that allows for direct lossless import, do you?

By the way: do you have a problem hearing the tape with iMovie while you import? I get no sound, though the sound is there, finally. I've read this is a common issue that I'm trying to solve. Thanks!

[Christina]

If you open an MP4 file with Subler, you'll see that, and you'll be able to adjust that. If you have an MP4 file that looks distorted, you don't need to reencode it, but to correct the pixel ratio values with Subler.

Good to know! I have already downloaded Subler so I'll keep that in mind if I encounter any issues. Thanks.

[celsoac]

If you open an MP4 file with Subler, you'll see that, and you'll be able to adjust that. If you have an MP4 file that looks distorted, you don't need to reencode it, but to correct the pixel ratio values with Subler.

Good to know! I have already downloaded Subler so I'll keep that in mind if I encounter any issues. Thanks.

Subler is absolutely fantastic and easy to use to mux tracks, define main audio tracks (in dual movies, for example), add subtitles, change video resolution, convert MKV to MP4 (without reencoding), etc. Just one piece of advice: if you are going to, say, add a track or do something heavy on a long file that is prone to be hung, use a copy, as if Subler hangs and you abort the resulting file is unsolveably damaged, unreadable.

[Christina]

So, I am also using and OLD version of iMovie which outputs DV, as you do, which is the only one that does NOT break the recording due to out-of-sync or to dropped frames. Final Cut Pro X, which is great for editing, does not have a "manual" option to avoid those breaks. In my experience, DV encodes very well in Final Cut Pro. I also archive in DV and make viewable versions in MP4.

Uh oh, a DV fan. Watch out - you may get your head bitten off on this thread. I also finagled the old iMovie HD to install on my OS (which is also old, 10.10) since the new iMovie doesn't see analog video without a timecode like Digital video has. I also used a small app I found called Vidi which works just fine for DV capture too, as far as I can tell.

As to lossless encoding, I also did encoding to AVI with Pinnacle in Windows, but I haven't found any app/system in Mac that allows for direct lossless import, do you?

If you have a Mac computer that you can add a capture card to (I don't - I have an iMac where everything is basically in the monitor, and a Macbook Pro Laptop), then I presume you could install a capture card like the AJA and capture completely uncompressed or I assume possibly a lossless codec, whatever is available in the AJA software or whatever you use to capture. I don't know for sure as I don't have a setup that will allow this.

By the way: do you have a problem hearing the tape with iMovie while you import? I get no sound, though the sound is there, finally. I've read this is a common issue that I'm trying to solve. Thanks!

I don't have that problem actually and so I don't know much about it. I would try the Vidi capture app or something else, and see if you can hear it there, determine if it's the hardware on your computer or something iMovie is doing. In my iMovie, I can hear the audio while I capture and it was like that from the beginning.

[Cornucopia]

FYI, ProRes supports all the usual framerates: 23.976, 24, 25, 29.97, 30, 59.94, 60. As one would expect for a pro-level codec. So it should be straightforward to go DV @ 29.97 -> ProRes @ 29.97 (or vice-versa) and keep sync. Just don't choose, or let it choose, 30. Then, for obvious reasons, you would get desync.

Scott

[celsoac]

[QUOTE=Christina;2547798]

I don't have that problem actually and so I don't know much about it. I would try the Vidi capture app or something else, and see if you can hear it there, determine if it's the hardware on your computer or something iMovie is doing. In my iMovie, I can hear the audio while I capture and it was like that from the beginning.

I also have an iMac. Thank you very much about Vidi, didn't know about it. If it encodes like iMovie and I can hear the tape while importing, that's all I need. Apparently this is a common issue with old iMovie. I really don't know why FCP or iMovie don't have the option to import "manually" without worrying about time breaks.

It is true that DV compresses more than ProRes. But I personally haven't found any difference in color, chroma, bleeding, etc. The only potential issue is that DV interlacing is opposite to that of ProRes, that is, the dominant field is lower (even lines) instead of upper/odd. When converting a DV file with good old MPEG Streamclip (a great option, as it is very versatile) that's all you have to keep in mind. DV does look crappy in some viewers (codec issue?), but not when converted to MP4 etc.

[Christina]

Also I should add before someone pounces on me - I am not the expert here, but I've also learned from hanging around these forums that supposedly Aja and Blackmagic are not great options for capture UNLESS you have a superb VCR and TBC between your tape and your computer. So, there's that.

[celsoac]

FYI, ProRes supports all the usual framerates: 23.976, 24, 25, 29.97, 30, 59.94, 60. As one would expect for a pro-level codec. So it should be straightforward to go DV @ 29.97 -> ProRes @ 29.97 (or vice-versa) and keep sync. Just don't choose, or let it choose, 30. Then, for obvious reasons, you would get desync.

Scott

Yes, of course, thanks. But perhaps when capturing a VHS tape with an external converter and QuickTime (the method that Christina was discussing), QuickTime uses 30fps by default. You can't select fps when capturing that way, only quality (ProRes or H264, I believe). QuickTime also captures screens or input from an iPad, and I believe it always does it at 30fps.