> But the same applies to a capture. As soon as it is digital, it isnt the same like > the original anymore.
And that's understood. However:
> The argument to be able to recreate a LD and "press" it again > is weak and nonsense, as we cant do this process anymore.
Right, but like I said further down: that's the theoretical goal. We know that we can't press laserdiscs anymore; the idea is that if the processes existed to do so, we could, and from digital data derived from an analogue source. No, those subsequent disc pressings wouldn't be the same as those originally manufactured commercially - but if they are at least usable then they're at least close enough to new pressings from an original pressing master. Not perfect copies, but close enough.
> What remains is, how you > feed the hardware and since this process will be a analog-digital-analog conversion > again and it doesnt matter how you do it, be it like the devs intend to do or be it a > capture, the argument is pointless. Yes, the intended way would be in theory maybe > more accurate, but it is way more "pain in the ass" to setup, for a result that you > cannot see with your eyes or hear with your ears.
OK, I think I might see one point where we're differing on this.
My intent is for VBI data to be captured from laserdisc in a way that, when converted back to analogue from a digital file, the VBI data is readable and usable by an actual laserdisc player.
Video quality (meaning the quality of the displayed image) is a secondary concern to me. That's not to say that it isn't important or that the VBI data isn't dependent on the capture quality of the entire frame, but rather that there will be losses as part of the analogue-to-digital-to-analogue conversion process which will possibly be human-detectable. But that's part of figuring out acceptable losses in that process, and determining what can and can't be lived with.
No, this doesn't mean that going for the highest quality of capture possible shouldn't be a goal, but rather that my particular interest is reliably reproducing the VBI and the data that it contains. Getting the sharpest possible image is also important, but from the standpoint of machine emulation, you rightly pointed out earlier that the game generally doesn't care what the content of the video is - but it definitely cares about what's in the VBI, though usually indirectly.
We need both parts; that's not up for question. But I'm focussed on the data needed for control more than on the image needed for interaction.
> This is simply not true. If you would feed Dexter with a good capture, it would be > exactly what you tried to explain. Dexter just uses JPG streams, which fits better on > a USB stick and is better to distribute. Of course these streams are lower in > quality, but the principle is the same like Domesday86 or what Dave did with his > Firefox and Dexter seems to emulate most of those LD-players already. If that wouldnt > be the case, the PCBs from the originals, wouldnt accept Dexter and the files.
OK, but (and, again, not a DEXTER owner, so may be wrong about this) I don't believe that DEXTER cares about the VBI data and instead does some sort of on-the-fly translation of LD player seek requests to a specific point in a video file. Perhaps it even uses framefiles or some other DAPHNE-style method; I really don't know.
What I would be interested to see is if, with the video that DEXTER uses, VBI data can be inferred from that video and acted on by a player. I don't believe that it can, but if it can be, then DEXTER is way ahead of just about everyone else in terms of LD preservation - and a good chunk of this thread may be a moot point since DEXTER would fundamentally contain a huge part of the solution already.