My C64 YouTube links for demos etc. are rejected with the words: no :: 60hz crap
category: general [glöplog]
Quote:
Smaller than what? Full frame dumps? Or do you mean full-state snapshots?
Full-state snapshots, yes, but only every second or so.
Quote:
I mean, it just seems like a more to emulate to have to emulate the full system over just the VIC.
Well, the thought would be to use an existing emulator, as opposed to have to rip out the VIC/SID parts. If you wanted to code the entire thing from scratch, then sure, it would be less work just to implement the chips and store register dumps per-frame somehow (essentially making it a very unusual video codec).
Quote:
So is watching via emulator vs. video capture from real hardware.
Depends on the watcher. I've had people mistake real hardware captures for emulators :-)
Anyhow, if people feel forward-skipping through space (whenever the coder added support for that) or warp is an adequate replacement for fully seekable videos; go ahead, watch demos that way. I won't stop you. But I'm not really watching things, especially oldschool prods, without seek anymore. I doubt I'm alone.
(I'm also not going to spend all the energy needed to make a seekable online emulator, I just consider it an interesting idea)
SID dump wouldn't be a problem; every key frame only needs the register values, DCO phase accumulator state, and EG state. That's like 50 bytes per frame, everything else can be reconstructed from there. (filter state etc would initially be wrong but settle after a couple millisecs, good enough for seeking I'd say)
Quote:
And that's why videos are popular. :) (Recorded from realthing, ofc.)But I'm not really watching things, especially oldschool prods, without seek anymore. I doubt I'm alone.
Aaaaand here is a selection of C-64 demos of agreeable duration that won't bore you to death with zillions of scrollers. :D (Fully seekable.)
Like I wrote here in the comments of YouTube: "The capture scene police was here. I capture again in 50Hz": C64: SCS*TRC Intro 09 [1995]: https://www.youtube.com/watch?v=Immazsi8cSA
I wrote also on the first page of this thread: "... But I can ofcourse capture in 50hz again. ..."
I like that you discuss different topics about capturing releases and all the different Hz settings, of different systems, in this thread now.
I wrote also on the first page of this thread: "... But I can ofcourse capture in 50hz again. ..."
I like that you discuss different topics about capturing releases and all the different Hz settings, of different systems, in this thread now.
Wondering. Just innocent questions,mind you. Do you guys watch movies without fastforwarding? Do you listen to full music albums?
I must admit, when listening to a music album I sometimes skip the 15 minute scroller parts.
I must admit I rarely (read almost never) watch things that feature 15 minute scrollers.
Quote:
Do you guys watch movies without fastforwarding?
I skip the scrollers during movies. Fortunately, they mostly seem to come at the end.
Last season of Picard is pure avantgarde in this regard imho. They put (great) opening titles at the end of each episode. So, watch it if you want, but we won’t force you. A stroke of genius.
Quote:
Well, you also need your capture device to be generous enough to capture the resulting HDMI signal. The OSSC can convert C64 to HDMI just fine (assuming you have something to decode the Y/C signal into RGB before it), but most devices won't like a 50.12 Hz HDMI signal.
Sounds like you are mixing up things that should be separate - "capture device" does not imply "HDMI" for that matter (as said before, those good old analog capture things with bt-something chip can do it fine - and no HDMI is involved, ever)
"assuming you have something to decode y/c into rgb" worries me a bit though. So you have 3 devices there to deal with, all introducing their own quirks and problems, and using an intermediate transport stream (HDMI) that apparently isn't up to the task. So yeah, that wont work well :)
Quote:
I skip the scrollers during movies. Fortunately, they mostly seem to come at the end.
I'm one of those weirdos who stays in the cinema until the credits are completely done - love the subtle things that are hiding in there often
Quote:
and using an intermediate transport stream (HDMI) that apparently isn't up to the task
The first step is analog. (But yes, there are lots of devices.)
Does RetroTINK mini work as promised?
For that money it better does :D
A bit late to the party, but I have been obsessing over my C64 capture methodology for a while now. I was planning on doing a writeup on all of this eventually, but I guess I better chime in now...
First off, I ultimately decided that emulator captures, specifically of the C64, will always suck. Why? The C64 has so much analog weirdness in its output, between both the VIC-II and the SID, that is virtually impossible to emulate "faithfully." Hell, I think even the "easier-to-emulate" 8580 implementation in the latest VICE release still has a super bugged filter (incorrect cutoff frequencies and weird self-oscillation). Not to mention how mushy the video output is on a real machine, even direct from the VIC-II chip.
With that said, my capture chain is as such:
From there I save my captures locally as AV1 since I have the hardware to encode it, and the file sizes are pretty nice. It does mean YouTube's transcode step takes forever, though.
As for other minutia:
In the end, my captures look like this. To be honest, I have lost motivation to continue doing them very much, both out of demotivation from crappy emulator captures getting many times more views, but also out of greater respect for demo authors who don't want some rando on YouTube uploading their work. Note that the older captures on my channel are not all using the methodology I described, as it's been an evolution over time.
First off, I ultimately decided that emulator captures, specifically of the C64, will always suck. Why? The C64 has so much analog weirdness in its output, between both the VIC-II and the SID, that is virtually impossible to emulate "faithfully." Hell, I think even the "easier-to-emulate" 8580 implementation in the latest VICE release still has a super bugged filter (incorrect cutoff frequencies and weird self-oscillation). Not to mention how mushy the video output is on a real machine, even direct from the VIC-II chip.
With that said, my capture chain is as such:
- First, my C64 has a modern RF modulator replacement, which is implicated even in S-video output. Modern amplifiers make the signal a little less smudgy.
- Then, I use a good quality video cable. In my case, I went pretty extreme and built one myself from Belden 1855A coax. Surprisingly, I did notice an improvement in luma/chroma crosstalk (evident as "checkerboarding" on strong colors like dark blue) after building that cable.
- The video signal is digitized with a RetroTINK 2x mini. Yes it does work pretty well @4gentE. I am interested in upgrading to something like the RetroTINK 4k, which has a completely custom S-video frontend instead of an off-the-shelf chip, but given the situation in the USA right now, I actually can't even order one anymore, even if I did have the money.
- The HDMI signal is captured with a cheapo MS2130-based USB capture card. By default the chip does some gross image processing, but there are actually hacks to make it capture fully lossless 4:2:2 YUV. Since the Tink2x is a line doubler, the chroma subsampling makes no difference in this case. Even then, since PAL has limited vertical chroma resolution, I think it still would be fine.
- Finally, I upscale the line-doubled 720x576 video in a way I deem "correct." That is, the signal is further stretched vertically with a nearest-neighbor filter, but horizontally with a sinc filter. Because each analog video line is a continuous, band-limited signal, it makes the most sense to scale it horizontally in a signal-theoretically "perfect" way. In practice, sometimes using Lanczos filtering, which is a variation on sinc, looks a bit better due to reduced edge ringing. Likewise, since video lines are completely disjoint in a real analog signal, no interpolation should be applied vertically.
From there I save my captures locally as AV1 since I have the hardware to encode it, and the file sizes are pretty nice. It does mean YouTube's transcode step takes forever, though.
As for other minutia:
- Framerate: I think the Tink2x is buffering frames and occasionally duplicating/skipping to tolerate the true 50.12Hz signal. It's not ideal, but everyone else here seems to agree that supporting such an odd framerate is basically impossible anyways, so I think it is fine.
- Aspect ratio: I have not validated whether or not the aspect ratio from the Tink2x is "correct." C64 pixels are a little narrower than 1:1, but to my eyes, my captures seem a bit too narrow yet, so maybe I'm too used to looking at bad emulator captures, or maybe something is wrong.
- Visible area: Interestingly, the Tink2x is able to capture the entire PAL frame. That means the luma spike at the start of each line on the C64 (I have validated this as real with an oscilloscope) is visible. I ought to crop it out, as it's a little unsightly, but I have been to lazy so far. Likewise, more of the borders are visible than any standard emulator capture I have seen.
- Audio sync: I use the Tink2x to also capture audio. That way, the audio and video are in as perfect of capture lockstep as I can manage, versus say using a separate USB audio interface, which has the potential to drift over time.
In the end, my captures look like this. To be honest, I have lost motivation to continue doing them very much, both out of demotivation from crappy emulator captures getting many times more views, but also out of greater respect for demo authors who don't want some rando on YouTube uploading their work. Note that the older captures on my channel are not all using the methodology I described, as it's been an evolution over time.
Quote:
my C64 has a modern RF modulator replacement
I don't recommend this for faithful captures - it makes the picture better than it should be, certain graphics will look wrong, since the replacement eliminates the so called "black bleeding". (see https://csdb.dk/release/?id=81780 - ignore the ancient comments though, back then "we" still thought this effect is related to a VICII glitch, but its not, its really the modulator)
PS: you don't use the infamous 330Ohm in the chroma line though?
@Rastertail: that capture you linked looks perfect to me.
I have this long time but extremely slow burn idea to build a perfect capture setup where I’d capture the actual CRT with a camera direct in front, all blacked out with black cloth. Of course there are lots of potential problems, but tbh my main problem is that I use pro monitors (I have 2 Sony PVMs, one JVC). These monitors are too precise IMHO, so the empty black space between the scanlines is a bit annoying. 3 years ago I stupidly skipped on a Commodore 1901 monitor which I think would have been perfect for the cause.
I have this long time but extremely slow burn idea to build a perfect capture setup where I’d capture the actual CRT with a camera direct in front, all blacked out with black cloth. Of course there are lots of potential problems, but tbh my main problem is that I use pro monitors (I have 2 Sony PVMs, one JVC). These monitors are too precise IMHO, so the empty black space between the scanlines is a bit annoying. 3 years ago I stupidly skipped on a Commodore 1901 monitor which I think would have been perfect for the cause.
Quote:
It's not ideal, but everyone else here seems to agree that supporting such an odd framerate is basically impossible anyways, so I think it is fine.
I don't think it's impossible at all, but it probably requires either building some part of your pipeline yourself, or getting lucky with equipment.
I do respect the amount of care you are putting into your capture, though. I can disagree with some quibbles (e.g., I don't think nearest-neighbor is the best approximation to the scanlines you'd get from an every-other-line signal on a CRT), but overall it sounds like a good pipeline.
Playing it back at proper 50,125Hz is probably more of a problem than producing a capture at the rate :)
Well, there are three possible ways you can look at that:
1. For compression, it's best if one compressed frame == one actual frame, regardless of playback. Exact duplicates are not a huge problem, but often, there's some form of noise so that you get an almost-but-not-quite-equal-frame.
2. If you are playing back on something that's not 50 Hz, it's no worse to have 50.12 than 50. E.g., on a 60 Hz display, you will get each and every frame played back (no skipping, ever), although you will have slightly more jitter every 8th second. The higher up you go in refresh rates (gaming monitors go to 300 Hz and such these days), the less jitter you will have.
3. Get a G-Sync/FreeSync monitor already :-)
1. For compression, it's best if one compressed frame == one actual frame, regardless of playback. Exact duplicates are not a huge problem, but often, there's some form of noise so that you get an almost-but-not-quite-equal-frame.
2. If you are playing back on something that's not 50 Hz, it's no worse to have 50.12 than 50. E.g., on a 60 Hz display, you will get each and every frame played back (no skipping, ever), although you will have slightly more jitter every 8th second. The higher up you go in refresh rates (gaming monitors go to 300 Hz and such these days), the less jitter you will have.
3. Get a G-Sync/FreeSync monitor already :-)
BTW i tested this, probably 15 (or more?) years ago, with an analog capture card (with said bt-something chipset), a C64, and a 1701 - which i also used for playback via some oldish nvidia card with tv-out
and guess what - it worked perfectly in every aspect, the recorded videos were indistinguishable from the C64, and no stuttering or dropped frames whatsoever.
So really - there are no excuses. Not a single one.
and guess what - it worked perfectly in every aspect, the recorded videos were indistinguishable from the C64, and no stuttering or dropped frames whatsoever.
So really - there are no excuses. Not a single one.
PS: now that i wrote it - back then i did also not use this 330 Ohm resistor. Analog Tuners can tolerate the slightly too high chroma level, i guess :)
Quote:
Playing it back at proper 50,125Hz is probably more of a problem than producing a capture at the rate :)
I'd say that a frame-preserving time-stretch to exactly 50Hz is strongly preferable to skipping a frame every 8ish seconds. It means the audio pitch will be off by a few % of a semitone, but I daresay even fewer people will notice that than the frameskip. :)