ADVC 110 PAL composite signal from Commodore 64 jitters/flickers

[Mr.Mouse]

Hi there,

I hook up my PAL version Commodore 64 to the ADVC 110 and wish to record in PAL mode. Now, I see the image, which is in full colour, but it is unstable/jittery. When I record with Premiere or Studio the resulting video file clearly shows this jitter as well. Any ideas?

[SoundFreak]

Resolution and / or refresh rate miss match ?

[Mr.Mouse]

Resolution and / or refresh rate miss match ?

Okay, well, do you also know how to correct this? The PAL signal is probably not 720 wide, as the C64 is originally usually 320x240. The interesting bit is that in Edius the preview is jittered (and the "raw" clip too), but when I view the recorded clip in Edius the image is corrected (I guess the resolution is less and the lines sort of crunched into shape). Exporting then to MPEG or Canopus HQ AVI results in a clear image. However, motion is still a bit jittery, like scrolling text is not smooth.

[GrassValley_BH]

Scrolling text back, unless it was really a graphic, was never smooth back then.

Although it's sending out a 720x576 @ 50 Hz interlaced PAL image, the source is still 320x240, and probably less than 50 Hz, which would show up as apparent jumping or skipping.

[Mr.Mouse]

Smooth scroll was already possible on the Commodore 64. It even has hardware smooth scroll. No, the stutter in smooth scroll is due to the conversion to a digital image.

http://lipas.uwasa.fi/~f76998/video/modes/ There is a read on PAL along with some info on the Commodore 64 signal.

The PAL-B on the 64 has :
63 cycles per line, 312 lines at 50 Hz.
Or 160×200, aspect ratio of 4:5

The signal is also non-interlaced.

Here's a discussion that may reflect the current issue as well:

http://noname.c64.org/csdb/forums/?roomid=7&topicid=53055

So what are my options?

[Mr.Mouse]

Okay, so I have worked this out more by myself as I notice there is little interest from Canopus/Grassvalley Support for this customer issue.

They key seems to lie in the PAL standard support in the ADVC110 and capture software. Todays PAL standard is 720x576 interlaced graphics at 25 fps, or 2 interlaced fields of 720x288 at 50 Hz. My guess is that the ADVC110 only passes through such PAL signals, and performs no other processing.

The Commodore 64, as other 8-bit computers from that era, uses non-interlaced images (progressive scan). Thus, the two fields of 720x280 probably each contain whole frames instead of only the odd or even lines.

Indeed, using the excellent and free VirtualDub I can start applying filters to the (uncompressed) video I capture with the ADCV110 and Premiere. VirtualDub allows to separate the fields and only show one of them. This way, by selecting to show only field 1, the image is rock solid and sharp. It is bafling to learn that I need a free program to allow me to do this kind of hard core processing. A switch on the ADVC110 to toggle progressive or interlace mode would be all there is needed to fix this problem.

I will have to go to extensive after-processing to get the kind of image that I want. Thus, showing progressive video as interlaced has the twitter effect that ruins my image. it is fortunate that VirtualDub allows me to start correcting this problem. But at the cost of time.

[GrassValley_MD]

It is not a question of interest in the issue. It is a question of who has a computer that old to test on. I have not seen a commodore 64 in over a decade.


Mike

[GrassValley_BH]

There are a number of challenges with your input. First off, the source resolution is quite low. The source resolution of 200x160 has to be magnified over 3X to match PAL video resolution.

This means that a single-line move on the C64 results in a 3-line move in the video.

Combine this with the fact that it's progressive, now you're getting HUGE shifts between captured video fields.

I don't think you're going to have an easy time making the video look nice.

Personally, I would use an emulator on your PC and capture the emulator's output this case. Then you can avoid all the scaling and such involved in the C64's PAL output and do any necessary interlacing/upscaling after the fact, from a nice smooth clean image.

[Mr.Mouse]

Well, not necessarily. For one, emulators are not "the real thing" and especially output of the emulated SID chip is nothing compared to the actual SID chip. That aside, I can still try and fix this problem using AviSynth.

I've found (using VirtualDub's split-fields-and-show-them-next-to-eachother) that both Field 1 and Field 2 are sharp, excellent images of the C64 signal. In addition, as expected, Field 2 is one frame further in time.

The problem is here that Field 2 is misaligned. It is at least 4 scanlines too high, and possibly some horizontal misalignment as well.

Using AviSynth I have already written a script that fixes the 4 scanline issue by writing something like this in an .avs file:

AviSource=""myc64capturedvid"
AssumeTTF()
SeparateFields
Bf=SelectEven().Crop(0,0,720,284).AddBorders(0,4,0,0)
Tf=SelectOdd()
Interleave(Tf, Bf)
Weave()

The code first deletes 4 scanlines from the bottom of the frame in Field 2 and then adds 4 new at the top of the frame, effectively aligning the image 4 scanlines down. This did not look too bad at all, and I think I need a little more X-tweaking to get it right.

I'll post the final AviSynth script when I get it done, and also an example of the resulting video. :)

[Mr.Mouse]

Well, I've fixed it enough to be workable. Install VirtualDub and Avisynth (both free open source programs, check SourceForge)

1. Capture the PAL C64 signal through the Canopus ADVC110 in Premiere or other capture software and save it as AVI
2. Create a new myvideo.avs (or other name.avs) file in a folder where your captured AVI is.
3. Edit the .avs file with notepad and copy and paste my script

# The XeNTaX Foundation presents in 2008:
# AviSynth script to fix misinterpreted Commodore 64 signal
# Signal was captured with ADVC110 
# Script written by XeNTaX's Mr.Mouse (http://www.xentax.com) 
# ----------
Avisource("pathtomyvideo.avi")
AssumeTFF()
SeparateFields()
Tf=SelectOdd().Crop(0,2,720,286).AddBorders(0,0,0,2).Spline64Resize(384,288)
Bf=SelectEven().Spline64Resize(384,288)
Interleave(Tf,Bf)
AssumeFrameBased

4. Open the .avs file as a clip/video in VirtualDub
5. Notice how everything is quite in order. Manipulate and save at will!

The script first assumes that the picture is interlaced (which it is because of the wrong capturing). However, the two interlace fields 1 and 2 are actually whole consecutive frames of 720x288. So Field 1 is one frame before Field 2.

Okay, but the actual C64 signal is not 720x288, but 384x288. Pixels are not fully square on the C64 with a little less x than meets the y. So we need to resize.

The script fixes a misalignment of Field 2 paradoxally by moving the frame of Field 1 2 scanlines up. I do this, because of AviSynth restrictions. I take away the top 2 scanlines in Field 1 (the Odd lines) and add two black lines at the bottom. This way I align Field 1 with the misaligned Field 2. Sledgehammer: Trust me, I know what I'm doing. Consequently, I resize each frame/field to 384x288 and why not, because that will give me the 4:3 aspect ratio the C64 has anyway, with a slightly elongated pixel in vertical direction (double the x size). Then I tell AviSynth: "just kidding when I said it was field-based, it is actually frame based!" The video output will now be progressive and each frame will be in the right order.

An example of a thusly created video is here (80 mb):

This is the C64 demo Bonzieed, by Bonzai.

http://www.xentax.com/taoc/bonzied_compressed.avi

[GrassValley_BH]

Not that it should matter in this case as the source is progressive, but DV compression is lower field first.

There's actually nothing wrong with the capturing mechanics. It's really the C64's video output that's weird, as it's trying to "fake" a progressive output by tweaking the signal timings and halving the resolution.

Result looks decent, not sure if the peace signs look so jagged on the original display or not. I'm very curious to see what a black/white pixel checkerboard pattern capture looks like processed and unprocessed. Or alternative black/white horizontal lines.

[Mr.Mouse]

Here you go. A nice 256 byte demo by NoName. Checkerboard zoom. Converted to DivX.

I've also adapted the AviSynth script so the final AVI is 384x272 , the full frame c64 screen (including borders).

# AviSynth Script to fix misinterpreted Commodore 64 signal
# The C64 PAL has 384x272 resolution (including borders) 
# This script by XeNTaX's Mr.Mouse converts a 720x576 interlaced PAL capture 
# of the C64 signal at 25 fps to the C64 384x272 image at 50 fps. 
# http://www.xentax.com, 2008 
Avisource("chessboard256.avi")
AssumeTFF()
SeparateFields()
Tf=SelectOdd().Crop(0,2,720,286).AddBorders(0,0,0,2).Crop(32,0,656,272).Spline64Resize(384,272)
Bf=SelectEven().Crop(32,0,656,272).Spline64Resize(384,272)
Interleave(Tf,Bf)
AssumeFrameBased

Here's the AVI file: http://www.xentax.com/taoc/t2.avi

[2Bdecided]

A smart bit of AVIsynth scripting there Mr.Mouse!

The ADVC devices aren't forgiving of non-standard signals. You're lucky that it misbehaves so predictably.

btw, there are still chipsets around that can generate this non-interlaced mode (e.g. conexant bt860), and most modern (fully "digital") TVs are still built to accept it.

Cheers,
David.

[Mr.Mouse]

I have posted a reply in this thread to days ago, with a new and better script, and example movie as requested by GrasValley_BH. Can a moderator please approve that reply? Thanks.

[GrassValley_BH]

Sorry, the system thought your post was spam and I didn't notice.
What video codec is used in the AVI? My players are only playing audio.