AmaRecTV's "Internal RGB Conversion"

[Alwyn]

I found this on a site:

Amarec’s internal RGB conversion. As experts frequently warn, this process can clip "illegal" whites and blacks, permanently destroying detail in the highlights and shadows that a pure YUY2 capture in VirtualDub would have preserved.

So what this means is that if you use Amarec, make sure that your video levels are within the 16 to 235 range. Adjust the brightess and contracts on the levels screen to set it perfectly before you capture.

I'm banned from the site so have no way of making enquiries there.

My understanding is that the digitiser/capture card determines the levels, not the program. I also understand that if the captured file is opened in VDub, it is converted to RGB. The file is not captured in RGB by AmaRecTV (or VDub, for that matter).

Of course, the levels should be set within the limits, but the capture program has nothing to do with the values set.

Any thoughts on the veracity/correctness of the quoted claim?

Edit added 13 April:
The poster has since made the following post:

Need to correct myself. Another thread [this one] at another forum has convincingly proved that this is incorrect. In fact, Amarec will produce YUV color space files if you pick a codec that uses YUV. So, that is great news.

[Sharc]

@Alwyn: As I understand it, this concern refers to AmarcTV's PREVIEW only. For the preview the YUV data have to be converted to RGB. AmararecTV uses the standard expanding Rec601 matrix, means luma 235 becomes RGB 255, and luma 16 becomes RGB 0. In other words any YUV data in the range (0...15) or (236 ... 255) get clipped in the PREVIEW, but not in the capture as long as one captures to YUV (YUY2 etc).

Other capture SW (like Vdub, but I would have to check) may use the studio matrix for the preview, which does not clip but returns a lower contrast preview picture. Depends on the tool's renderer.

What happens one can readily verify using standard test patterns with known YUV data.

How one eventually treats the captured YUV data depends on the subsequent processing steps. Take note that some editors treat the YUV data differently, already at import. So it's usually good practice not to intentionally capture into the 0..16 or 236 ...255 luma range (8 bit realm), unless one is aware of the consequences.

[Alwyn]

Thanks Sharc, could it therefore be that this "characteristic" is a good thing, because AmaRecTV would display any whites and blacks captured in the 0-16 and 236-255 range as blowouts, thereby prompting the operator to adjust the levels?

[Sharc]

Thanks Sharc, could it therefore be that this "characteristic" is a good thing, because AmaRecTV would display any whites and blacks captured in the 0-16 and 236-255 range as blowouts, thereby prompting the operator to adjust the levels?

No idea. We would have to ask the developpers.
Sidenote: In some more recent tests with the USB-Live2 I found that it "downsteps" excessive luma in the 236...255 range gradually to below 235. Sometimes it does it a bit too much even. See my posts on this. The GV-USB2 doesn't do this. So it's up to the user to consider this a benefit or a flaw.

[lollo]

Alwin, i do not know where you read that, but is completely false.

AmarecTV properly captures in the YUV range. No internal conversion to RGB is performed.

An example of a GV-USB capture with AmarecTV of a source in 0-255 YUV range:


A conversion to RGB (emulated here in AviSynth) and back to YUV would produce this:


@Sharc, reading the original post included by Alwin, I do not think that the OP meant the "display" environment, he mentioned the "pure YUV capture" and "video levels", so clearly he does not know what he's talking about.


edit: I found the source, is a digitalFaq post https://www.digitalfaq.com/forum/video-capture/15658-vhs-audio-sync.html. Among the whole amount of non-sense about AmarecTV, this one is pure fantasy:

on this forum argue that while AmarecTV seems more stable, it’s essentially masking the underlying signal issues. VirtualDub 1.9.11 is generally the gold standard because it’s brutally honest. It reports every dropped frame and timing jitter.

It is the opposite. AmarecTV reports in detail what's happening during the capture, with all the information needed to understand where the inserted and the dropped frames are located. VirtualDub just provides a counter. Both drops/inserts frames when is needed. The amount of mis-information about capture softwares and modern cards on that site is unbelievable.

[The 14th Doctor]

It is the opposite. AmarecTV reports in detail what's happening during the capture, with all the information needed to understand where the inserted and the dropped frames are located. VirtualDub just provides a counter. Both drops/inserts frames when is needed.

I know with Amarec you can enable it to write out a log detailing this information, but with VirtualDub once any drops or inserts are detected you can find out where they are in the final captured file by using the ctrl + ] and ctrl + [ shortcuts once the capture file is loaded up.

With any duplicate frames VDub adds in being labeled as 'D' in the timeline

Are they not doing the same thing here, just in different ways? This isn't meant to be all 'Amarec bad VDub good' funnily enough did a Amarec capture in which VirtualDub was able to detect duplicate frames in it.

I'd try AmarecTV if Pinnacle cards worked with it but alas, they do not. That or I just can't find any fix for the error Amarec throws up. Can only use it with an IO-Data, but that's adding two changes in the chain, not one, so imo it's not fair enough to compare.

[lollo]

I know with Amarec you can enable it to write out a log detailing this information, but with VirtualDub once any drops or inserts are detected you can find out where they are in the final captured file by using the ctrl + ] and ctrl + [ shortcuts once the capture file is loaded up.

With any duplicate frames VDub adds in being labeled as 'D' in the timeline

The problem is that in VirtualDub there is no information about the positioning of the dropped frames (and by mistake the inserted frames are called dropped frames in the menus). So you have no indication of where they happened in time.
Moreover, when a frame is inserted because a previous dropped frame, in AmarecTV you have all the info to understand where the frame was lost and where the stream has been corrected to compensate. Impossible with Vdub.

The visual positioning inside Vdub software in editing mode is available with any capture, and it can be found even with a text editor of the stream. When inserting a frame, the capture software obvioulsy does not write it again but just places a string of bytes instructing to repeat the previous frames.

I gave many example of the mechanisms through AmarecTV reports, do I really need to discuss about that any further?

Are they not doing the same thing here, just in different ways? This isn't meant to be all 'Amarec bad VDub good' funnily enough did a Amarec capture in which VirtualDub was able to detect duplicate frames in it.

One is doing better. I already wrote about what an inserted frame is and how to detect it.

I'd try AmarecTV if Pinnacle cards worked with it but alas, they do not. That or I just can't find any fix for the error Amarec throws up.

The second.

Can only use it with an IO-Data, but that's adding two changes in the chain, not one, so imo it's not fair enough to compare.

You can use the GV-USB with Vdub and AmarecTV and compare. I will be waiting for your results in your specific enviroment, which is always nice to add as a "fact".

[The 14th Doctor]

I've read this thread, and unless I'm dumb I couldn't find a solution to the problem when reading the posts there.

I know what a inserted frame is, is it not a duplicate of the previous frame that a capture program adds in order to help prevent further audio sync? Since when did you tell me specifically this information?

Now a dropped frame is one that is lost, but not compensated for at all. I've only dealt with insert frames very rarely, not drops. Though I will agree, sucks how drops and inserted frames are treated the same when it comes to finding them using VirtualDub's timeline.

I've also been told that disabling inserts in the timing settings just disables them from being reported.

Is something like frame 1000 at 00:30:033 being a normal frame and frame 1001 at :00:30:066 being labelled as inserted frame not enough information? I guess not..

I've used an IO-Data in both VDub and Amarec, they are fine. But overall I prefer using a Pinnacle 710 or 510 because 1. I am use to it in terms of having the proc amp setup, so overall colors and 2. Prefer the audio sync with the Pinnacle, it is more consistently in sync, granted yes it's out of sync by one frame due to an external TBC adding in a one frame delay but the audio never goes further out of sync so I can easily correct it post capture by adding a delay of one frame (33ms) in VirtualDub by using the audio interleave function.

Those are my preferences anyway, an IO-Data and Aramrec are probably fine enough choices, but they aren't better than what I've been using. Not trying to say they are crap, because they are not. Granted I am somebody who doesn't mind using 2010s era laptop with XP or 7 on it.

[lollo]

I know what a inserted frame is, is it not a duplicate of the previous frame that a capture program adds in order to help prevent further audio sync?

It is a duplicate of the previous frame, but is not written as such in the captured stream. Once more, the capture software writes in the stream a specific patter instructing the "player" or the "editor" to repeat the previous frame.
How do you think that VirtualDub in editing mode is able to find them? By reading that pattern (it does not perform a real time frame matching obviously). In one of the capture software I wrote I also explored to add a byte in an inserted frame while keeping it in its integrity, but is useless.

Since when did you tell me specifically this information?

Not to you directly, but I wrote nth times about it.

Is something like frame 1000 at 00:30:033 being a normal frame and frame 1001 at :00:30:066 being labelled as inserted frame not enough information? I guess not..

See above.

I've used an IO-Data in both VDub and Amarec, they are fine. But overall I prefer using a Pinnacle 710 or 510 because 1. I am use to it in terms of having the proc amp setup, so overall colors and 2. Prefer the audio sync with the Pinnacle, it is more consistently in sync, granted yes it's out of sync by one frame due to an external TBC adding in a one frame delay but the audio never goes further out of sync so I can easily correct it post capture by adding a delay of one frame (33ms) in VirtualDub by using the audio interleave function.

Those are my preferences anyway, an IO-Data and Aramrec are probably fine enough choices, but they aren't better than what I've been using. Not trying to say they are crap, because they are not. Granted I am somebody who doesn't mind using 2010s era laptop with XP or 7 on it.

Thanks for confirming that: 1) AmarecTV is a nice capture software not introducing any regression compared to VirtualDub, 2) GV-USB2 is a nice capture card not introducing any regression compared to a Pinnacle 710 or 510.

Just as a side note, with old cards (Pinnacle) and old Operating Systems (WinXP or 7), VirtualDub can be used (but AmarecTV is still better, and you can have the same performances with a modern card and a modern Os)

Prefer the audio sync with the Pinnacle, it is more consistently in sync

Just for my curiosity to understand the results in your specific case, "more consistently in sync" compared to what? You wrote that you cannot use AmarecTV with that card, so you are comparing who versus who?

[The 14th Doctor]

I've never read deeply into the whys of it all so I apologize.

And I get what you mean, if people don't want to bother with getting an old PC or laptop then so be it. I'm just saying I am somebody who is more than fine with using an old 2013 Dell Latitude as a capture laptop, then transfer the files to a 2022 Lenovo Thinkpad mobile workstation laptop for restoration work (that's what I do)

The comparison was with using an IO-Data with VirtualDub compared to a Pinnacle 710, also in VirtualDub.

Though that was with the IO-Data capture timing settings set up so that the audio corrects itself by adjusting it's timing, with the Pinnacle 710 the timing settings are setup so that no audio/video syncing is done by VirtualDub.

The changes in timing settings lead to the IO-Data's audio varying wildly in sync, so the simple 'just delay the whole audio by 33ms and everything is now perfectly in sync' did not work.

Maybe I'll do another comparison someday, IO-Data using VirtualDub, same timing setting as used with the Pinnacle 510/710. I do know that the IO-Data inserts up to 4 frames at the start of capture, and I need to delay the audio by the amount of frames that were inserted. This was the same experience I had with an ATI AIW USB card.

So 3 frames inserted at the start = delay audio by 99ms, for example.

Basically from my limited testing I prefer the Pinnacles overall, but that's mainly because I am use to using them at this point after 3 years.

So I'd rather be consistent as possible and continue to use Pinnacles than switch to an IO-Data.

[lollo]

Though that was with the IO-Data capture timing settings set up so that the audio corrects itself by adjusting it's timing, with the Pinnacle 710 the timing settings are setup so that no audio/video syncing is done by VirtualDub.

Unfair.

Basically from my limited testing I prefer the Pinnacles overall, but that's mainly because I am use to using them at this point after 3 years.
So I'd rather be consistent as possible and continue to use Pinnacles than switch to an IO-Data.

Absolutely yes.

You have a working set-up, providing good quality, no reason to change until you're satisfied using old OSs and cards. But again, there are modern solutions providing equivalent or better results (that's always been my point, nothing more).

[Sharc]

Seems that almost any question or just mentioning of Vdub or AmarecTV ends up in a dispute about dropped/inserted frames - irrespective of the OP's original question

[lollo]

Seems that almost any question or just mentioning of Vdub or AmarecTV ends up in a dispute about dropped/inserted frames - irrespective of the OP's original question

Yes, unfortunately. See the original thread in digitalFaq

[Brad]

edit: I found the source, is a digitalFaq post https://www.digitalfaq.com/forum/video-capture/15658-vhs-audio-sync.html.

The user has replied with a correction based on your post.

Need to correct myself. Another thread at another forum has convincingly proved that this is incorrect. In fact, Amarec will produce YUV color space files if you pick a codec that uses YUV. So, that is great news.

He is also a member here. In fact, currently 64 posts here vs 7 there.

In my experience, his YouTube videos trying to help others are excellent. Nothing is perfect of course, but from what I see he presents to the best of his knowledge and is always learning more. As most of us hopefully are.

[lordsmurf]

I'm banned from the site

You're not banned. Your account is locked. Why? Your email is invalid. Fix that, and lock lifted. Feel free to PM me a valid email. In 20+ years, I doubt we've had to ban even 20 people.

Nothing is perfect

^ This.
Sadly, most people use that as an excuse to accept crap results.
But here at this site, and there at that site, some of us try. And we often disagree. Friendly disagreements, hopefully, though it can get heated.

The problem is that in VirtualDub there is no information about the positioning of the dropped frames

ctrl + ]
ctrl + [

granted yes it's out of sync by one frame due to an external TBC adding in a one frame delay but the audio never goes further out of sync so I can easily correct it post capture by adding a delay of one frame (33ms) in VirtualDub by using the audio interleave function.

That's the wrong take. Most audio is +/- several frames, especially in broadcasting. Analog was never 100% perfect even within the camera. Sound and light travel at different times, so it's actually impossible for "true sync" to exist anywhere.

Just as a side note, with old cards (Pinnacle) and old Operating Systems (WinXP or 7), VirtualDub can be used (but AmarecTV is still better, and you can have the same performances with a modern card and a modern Os)

- GV-USB2 is an early 2010s card design, while Pinnacle is late 2000s. That's the same USB capture card era.
- VirtualDub 1.9.x works perfectly in Windows 11.

I reject the term "old", or even "modern". Both the cards and software are "legacy". And that's perfectly fine. VHS is old. And it's being recovered with legacy tools, because nothing new (of better quality) exists.

[The 14th Doctor]

That's the wrong take. Most audio is +/- several frames, especially in broadcasting. Analog was never 100% perfect even within the camera. Sound and light travel at different times, so it's actually impossible for "true sync" to exist anywhere.

I understand that, audio is always going to be slightly out of sync between captures of the same VCR or different VCRs even with a TBC. It's analog, there is always going to be some small percentage of difference. But from what I've noticed, it'd only be off by less than 6 milliseconds.

What I'm trying to get at is that the external TBC adds in a delay of one frame, but since it only processes video and not audio, the audio is not compensated for the added frame delay.

So that means the audio in my captures is always off by one frame, but since the audio otherwise is in sync (ie it doesn't get further out of sync over time) I can easily match the audio back to it's proper timing by adjusting the audio forward by 33ms (which equals to one interlaced frame)

Now sometimes I'd have to adjust it by two frames, so 66 milliseconds, but that's because the tape has a one frame audio delay baked in.

In my opinion it's the same deal as those DVD recorders (ES10 / 15), they add in frame delays so the audio must be adjusted to compensate. Only difference is you can route the audio through the DVD recorders.

Edit - To demonstrate my point here are two images, one with the audio delayed by 66 milliseconds and one where the audio is not delayed.

The previous frame in the video is the end of a previous scene, so this frame is the start of a hard cut to a new scene. So pretty much I fixed the audio by delaying it by two frames, first to compensate for the one frame delay caused by the external TBC and the other by the one frame audio delay that's baked into the tape.


[Attachment 91908 - Click to enlarge]
[Attachment 91909 - Click to enlarge]

[Sharc]

What the heck does this have to do with the OP's original question??

[The 14th Doctor]

Nothing! I just felt like wanting to explain myself after LS' post.

So I apologize for partly derailing this thread. Guess I started that by taking to Lollo about Amarec, but I just wanted to know where he was coming from with his claims, wasn't here to argue with him but to understand why.

[lollo]

He is also a member here. In fact, currently 64 posts here vs 7 there.
In my experience, his YouTube videos trying to help others are excellent.

Yes, I contributed to some of his YT videos, and suggested to some users his channels! He's very friendly and helping many people (I did not recognize him at first).

I did not mean a personal attack to him, he's just following the falsehood written in that forum. Just read some of the later insane comments about "broadcast" or "myself writing but I know that sometimes the report is not accurate, and a card can drop frames without being reported by the capture software" without reading the context and the following facts where I meant in that thread the tested VirtualDub behaviour with some cards reported by jmac698 in doom9's forums. Complete bullshit, that I do not wish to comment any further there.

Nothing is perfect of course, but from what I see he presents to the best of his knowledge and is always learning more. As most of us hopefully are.

Agree 100%!

The problem is that in VirtualDub there is no information about the positioning of the dropped frames

ctrl + ]
ctrl + [

???

I wrote here, you can download the files and practice a bit: https://forum.videohelp.com/threads/416657-Analog-Capture-inserted-and-dropped-frames

- GV-USB2 is an early 2010s card design, while Pinnacle is late 2000s. That's the same USB capture card era.
- VirtualDub 1.9.x works perfectly in Windows 11.

- GV-USB can be bought new at a fraction of the price of the Pinnacle you sell. And performs equally or better.
- VirtualDub is not recommended with modern cards and modern OSs.

I reject the term "old", or even "modern". Both the cards and software are "legacy". And that's perfectly fine. VHS is old. And it's being recovered with legacy tools, because nothing new (of better quality) exists.

Reject what you want, but the terms are appropriate: "modern" cards are still in production, and "modern" OSs are recent, perfect with modern desktop/laptop hardware, in use and maintened.

[The 14th Doctor]

I wrote here, you can download the files and practice a bit: https://forum.videohelp.com/threads/416657-Analog-Capture-inserted-and-dropped-frames

Well I loaded the avis you gave for frame insert demonstration and VirtualDub reported one inserted/duplicated frame in the 'with problem' avi file, frame #209 at 0:08.360.

So how many inserted frames are in this file, just one or is that incorrect?

[lollo]

So how many inserted frames are in this file, just one or is that incorrect?

Just one.

I mentioned that old example only to reply to lordsmurf assertion about dropped frames, because in that thread there is also a sample with 1 dropped frame that, obviously, VirtualDub (or any other software) is not able to detect (you have trace of it only in AmarecTV log file).

[lordsmurf]

- GV-USB can be bought new at a fraction of the price of the Pinnacle you sell. And performs equally or better.

- It's still a 15-year-old hardware design.
- The price difference is not a fraction. GV-USB2 also has wild price swings on Amazon, because of forex and tariffs. Sometimes price difference is just $25.

- VirtualDub is not recommended with modern cards and modern OSs.

If you refer to HD cards like Blackmagic, sure.

I mentioned that old example only to reply to lordsmurf assertion about dropped frames, because in that thread there is also a sample with 1 dropped frame that, obviously, VirtualDub (or any other software) is not able to detect (you have trace of it only in AmarecTV log file).

This whole thing amuses me now.

So I've been telling you, for years, that AmaRecTV can drop/insert without proper reporting. And you disagree, of course, AmaRecTV (and GV-USB2) can do no wrong in your eyes.

And you can disable VirtualDub reporting with the wrong settings.

So you're telling me that you found a VirtualDub capture where 1 frame was not reported, where reporting was turned on?

And to prove this, I have to read this mini-novel of a post: https://forum.videohelp.com/threads/416657-Analog-Capture-inserted-and-dropped-frames
For 1 frame.

This is too much even for me. I just don't have the time to read all that (again?)
We have people still using Easycaps, Elgato, HDMI dongles, etc. But we choose to bicker over 1 dropped frame?
No, I'm out.
I'd rather cut the lawn with scissors. At least it's more calming.

Sometimes I just have to let people "win" an argument because they have more time that I do.

I like you lollo. But please, get out. Have a drink, get laid, watch a movie. Something. You should have more fun.

[lollo]

- GV-USB can be bought new at a fraction of the price of the Pinnacle you sell. And performs equally or better.

- It's still a 15-year-old hardware design.

So what? That's another story. A card is its hardware, its board, the rest of the BOM, the software, and the drivers.
And be sure that no one assembly 15-year-old ICs, they are manufactured in the silicon foundries just now.
In my company we still sell specific ASICs and ASSPs product designed 20 years ago (and ported to recent/esisting silicon nodes of course)

- The price difference is not a fraction. GV-USB2 also has wild price swings on Amazon, because of forex and tariffs. Sometimes price difference is just $25.

I bought for my organization tens of GV-USB and USB-Live 2 and never seen that.

If you refer to HD cards like Blackmagic, sure.

No, I use the blackmagic cards only for capturing digital content: https://forum.videohelp.com/threads/405502-YouTube-channels-playlists-showcasing-captu...eo#post2686067

So I've been telling you, for years, that AmaRecTV can drop/insert without proper reporting. And you disagree, of course, AmaRecTV (and GV-USB2) can do no wrong in your eyes.

I have never seen that behaviour across thousands of captures and comparisons with the same material available in other format that the analog recording.

And you can disable VirtualDub reporting with the wrong settings.

I never disable the first two options in VirtualDub timming settings, everybody knows that.

So you're telling me that you found a VirtualDub capture where 1 frame was not reported, where reporting was turned on?

And to prove this, I have to read this mini-novel of a post: https://forum.videohelp.com/threads/416657-Analog-Capture-inserted-and-dropped-frames
For 1 frame. This is too much even for me. I just don't have the time to read all that (again?)

No, misunderstanding here.

Some (many) years ago, on doom9 forums there where some experiment driven by experienced users to show that they were dropped frames in the captures not reported by VirtualDub. I recognized that, and suggested that may be the frames were dropped before the stream arrives to the card and the capture software, so it was a "limit" situation.

The link to my sample was to show about the usage of VirtualDub to find dropped frames in a captured stream you suggested, which is impossible.

I like you lollo. But please, get out. Have a drink, get laid, watch a movie. Something. You should have more fun.

I do, and I have a lot of fun in my life. Even when capturing analog signals