|
Re: Question about ALG driver status
[Re: casm]
#368035 - 07/20/17 01:42 AM
|
|
|
> That said, from having read through the MAMEtesters bug that you linked to, I'm not > sure what that would have to do with lossless storage in a CHD. The bug makes it > sound as though the real issue was that the video and audio were captured from a > damaged disc, and that damage would render the game unplayable past a certain point.
It's not about the lossless storage, but the capturing of frames from the Laserdisc player. What it has been discussed here is exactly the same method currently MAME uses to get Laserdisc information, this time with less scanlines captured (only 3 of choice). If you read further into the report you'll notice someone partially fixed the problem by separating audio from the CHD and hand editing the audio before reintegrating it back. So the problem was not exactly a scratched disc at all, but how the information was gotten.
|
|
|
|
Re: Question about ALG driver status
[Re: Rygar9]
#368036 - 07/20/17 04:02 AM
|
|
|
> > > OK, let me pose this question in relation to the above: does this mean that MAME > > > should also emulate the laserdisc players in their entirety for the games that > used > > > them? Digitised disc data could be fed to a virtual laser pickup, the VBI decoded > > > within the LD player virtual machine, and the appropriate frame data fed from the > > > virtual player's video output to MAME's framebuffer for display. > > > > Yes it should. And it should output the composite video so we can decode it in a > > programmable shader and provide a set of dynamic picture controls like you'd get > with > > a real system. > > > > > Granted, I am being slightly silly in asking that question, but not entirely. > Given > > > that we're talking about reproduction of an analogue medium in a digital format, > > > we're always going to be stuck with the 'how far do we go' and 'where do we stop' > > > questions. > > > > And people said storing home computer tape software as WAV files and emulating the > > front-end was silly (rather than just storing bytes), or emulating keyboard MCUs > and > > interface chips was silly (rather than just faking it at protocol level), and > > emulating CPS2 encryption was silly (rather than just using XOR files), or > requiring > > encrypted NeoGeo GFX ROM images was silly (rather than using pre-decrypted GFX like > > NeoRageX), yet here we are. > > Permit me another question? > > This seems to me to be crossing from emulation to simulation? > > The laserdisc is an analogue to a hard drive, so it feels to me like extending this > means that MAME should simulate the cylinders and head(s) of a hard drive, the IRQ's > generated, the ISA/PCI bus, memory controller, etc. The laserdisc player isn't really > that different from the hard drive as it is just the medium that reads out the bytes > stored on a "Storage platter". > > I feel like laserdiscs are being held to a higher standard than hard drives with > respect to being supported in MAME. Shouldn't the support requirements be the same > for both mediums? > > I completely get why we want to have the laserdisc itself converted into a series of > bits to represent the physical layout of data on the disc, I'm just wondering why the > laserdisc player itself isn't emulated? > > That requirement for the laserdisc player to be simulated seems to me to be the thing > preventing laserdisc inclusion in MAME as it seems to me to be setting an impossibly > high requirement. Though of course, since I've never been involved in MAMEDev > discussions I could be unaware of other requirements preventing it.
It is a higher standard because it is analogue. We need the best SQNRs that are practical. Even with good design every rip will be quite different and have a different fingerprint. This is because the data is left as is and is not quantized to discrete values. It contains the random variation caused by noise.
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368037 - 07/20/17 04:06 AM
|
|
|
Don't refer to me as 'you guys'. I'm just a contributor.
|
|
|
|
Re: Question about ALG driver status
[Re: casm]
#368044 - 07/20/17 11:56 AM
|
|
|
> > In my mind, the final "laserdisc dump" format should contain enough information that if someone had the ability to master a new laserdisc, that it would contain all the information required to do just that and result in a reasonable duplicate without significant data loss, understanding that with the number of analog-digital and digital-analog transitions we've been discussing here, wouldn't be exactly the same.>
> Agreed. And reconverting the digital conversion to analogue, sending it straight into the laser pickup of a player, and having the player both act on the VBI data and display the image it was sent would be an excellent demonstration of the success of the process without needing to build a disc-pressing plant.> >
Ok and how you would "sending it straight into the laser pickup of a player" without additional hardware or additional "cosmetic" work on the LDP itself? Tell us please. You still didnt answer the "significant data loss" question, so again what is lost and why it is significant?
Also, even the intended ideal setup is a analog-digital and digital-analog transition, the only difference would be that you dont have video-audio sync problems, but that can be solved, like Dave in the Firefox thread did.
This is nothing new btw., such stuff already exist, i.e. Dexter: https://www.youtube.com/watch?v=8Wu3sVFfFDc As you can see in the video, it is not much needed to fool the real hardware. The real hardware doesnt know, what kind of videostream (meaning the content here) is playing, it could be everything, as long as some specs are met.
The Domesday86 thread is indeed interesting, but if you look what simoni wrote: "As a minimum I'd like the 10-bit capture (@ 30MSPS), but the 20-bit 4:2:2 YCbCr with separate syncs would be even better." Its what my intended capture card (i wrote that already) would do: 10-bit, 4:2:2 (@ 30MSPS), sadly minus the seperate syncs, but that is a solvable thing. He prefer 20-bit, but this is taking a sledgehammer to crack a nut. I dont think it will make a difference and only create more data to backup. The card can capture up to 6 audio tracks btw., so even other LD systems could be covered. I admit, that i didnt think that global, as this thread was mainly about ALG or arcade systems.
> Don't refer to me as 'you guys'. I'm just a contributor. >
Please just spare me, with your ongoing pointless one-liners. Either write a concrete answer and be a (useful) part of the discussion, or just dont answer at all. Your last posts regarding me, are only childish insults. If i have no clue or i am wrong with something, try to explain it and explain it in a way that others can follow (i cant, simply by the fact that the answer is to short and full of abbreviations.). You only pick out stuff , where you are sure you can someone expose as a idiot. You ignore or answer questions that are still unanswered.
You should see, the good things in such a discussion, like the reveal of the Domesday86 project. Something you would miss, with your arrogant attitude and thoughts of "knowing everything".
Edited by uman (07/20/17 12:12 PM)
|
|
|
casm |
Cinematronics > *
|
|
|
Reged: 08/27/07
|
Posts: 668
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: BIOS-D]
#368046 - 07/20/17 03:14 PM
|
|
|
> It's not about the lossless storage, but the capturing of frames from the Laserdisc > player.
Right, that's understood. More:
> What it has been discussed here is exactly the same method currently MAME > uses to get Laserdisc information, this time with less scanlines captured (only 3 of > choice). If you read further into the report you'll notice someone partially fixed > the problem by separating audio from the CHD and hand editing the audio before > reintegrating it back. So the problem was not exactly a scratched disc at all, but > how the information was gotten.
Yes, I read that as well. However, it appeared to me that the hand-editing was done to compensate for what was a capture from a disc that was damaged; there's even speculation of possible errors in the pressing master as disc errors crop up at the same frame on real hardware as in MAME.
I'm just not seeing the connection in this case. Sorry, but I'll need you to explain to me in really simple terms the correlation that you're seeing because it's just not making it into my head for some reason.
|
|
|
casm |
Cinematronics > *
|
|
|
Reged: 08/27/07
|
Posts: 668
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368047 - 07/20/17 04:02 PM
|
|
|
> > > In my mind, the final "laserdisc dump" format should contain enough information > that if someone had the ability to master a new laserdisc, that it would contain all > the information required to do just that and result in a reasonable duplicate without > significant data loss, understanding that with the number of analog-digital and > digital-analog transitions we've been discussing here, wouldn't be exactly the same.> > > > > Agreed. And reconverting the digital conversion to analogue, sending it straight > into the laser pickup of a player, and having the player both act on the VBI data and > display the image it was sent would be an excellent demonstration of the success of > the process without needing to build a disc-pressing plant.> > > > Ok and how you would "sending it straight into the laser pickup of a player" without > additional hardware or additional "cosmetic" work on the LDP itself? Tell us please. > You still didnt answer the "significant data loss" question, so again what is lost > and why it is significant?
I can only answer the part of this concerning reproducing the digital data directly back into a player's laser pickup. Stiletto made the comment regarding significant data loss, so he'll need to field that one.
Regarding converting from digital to analogue and sending that analogue signal into the laserdisc player's laser pickup: that was a semi-serious comment, as evidenced by the ' ' at the end of the sentence. What it meant was that if a digital copy of the original analogue data could be converted back to analogue and played out through a laserdisc player, then we'd have a working conversion process.
It's a proof-of-concept - and a theoretical one at that at this point. Of course doing something like that would require hacking up a laserdisc player in some form or another; that would be unavoidable.
> This is nothing new btw., such stuff already exist, i.e. Dexter: > https://www.youtube.com/watch?v=8Wu3sVFfFDc > As you can see in the video, it is not much needed to fool the real hardware. The > real hardware doesnt know, what kind of videostream (meaning the content here) is > playing, it could be everything, as long as some specs are met.
True. But DEXTER can't meet the test case I outlined with converting back to analogue. Sure, it outputs analogue video (it has to in order to interface with the game's monitor), but the source material it uses isn't intended to be used to recreate a physical laserdisc; its purpose is to provide something for the monitor to display.
Think of it this way: if a CHD image is made of, say, a hard disk, that image should be able to be written back to another hard disk and used as intended, which would show that the imaging process was successful.
With laserdisc, there is nowhere on Earth (that I'm aware of) still in operation that is capable of manufacturing the discs. We can't call up Sony, or Imation, or Toshiba, and ask for a one-off made from {insert capture format here}. This means that we can't just have a disc pressed, stick it in a player, and say, 'yep, the conversion process works'.
This is where the somewhat tongue-in-cheek suggestion of converting back to analogue and shooting that straight into the laser pickup comes in. It's also something that DEXTER can't do by design. DEXTER can tell us if a game's PCB, monitor, audio, and controls are working as expected; it can't tell us if a given capture format could be used to generate a usable laserdisc from {insert capture format here}.
(Note: I don't actually own a DEXTER board. My reply above is based off of information I've gathered while looking into them as something I may want to acquire. My responses may not be 100% correct as a result; anyone reading this is encouraged to verify my statements.)
> > Don't refer to me as 'you guys'. I'm just a contributor. > > > Please just spare me, with your ongoing pointless one-liners. Either write a concrete > answer and be a (useful) part of the discussion, or just dont answer at all. Your > last posts regarding me, are only childish insults. If i have no clue or i am wrong > with something, try to explain it and explain it in a way that others can follow (i > cant, simply by the fact that the answer is to short and full of abbreviations.). You > only pick out stuff , where you are sure you can someone expose as a idiot. You > ignore or answer questions that are still unanswered. > > You should see, the good things in such a discussion, like the reveal of the > Domesday86 project. Something you would miss, with your arrogant attitude and > thoughts of "knowing everything".
Was this directed at me or Stiletto? I certainly never said this, and can't find where he did, either. It's rather confusing.
|
|
|
|
Re: Question about ALG driver status
[Re: casm]
#368048 - 07/20/17 05:21 PM
|
|
|
Quote:
> Regarding converting from digital to analogue and sending that analogue signal into the laserdisc player's laser pickup: that was a semi-serious comment, as evidenced by the ' ' at the end of the sentence. What it meant was that if a digital copy of the original analogue data could be converted back to analogue and played out through a laserdisc player, then we'd have a working conversion process.>
But the same applies to a capture. As soon as it is digital, it isnt the same like the original anymore. The argument to be able to recreate a LD and "press" it again is weak and nonsense, as we cant do this process anymore. 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.
Quote:
> It's a proof-of-concept - and a theoretical one at that at this point. Of course doing something like that would require hacking up a laserdisc player in some form or another; that would be unavoidable.>
> True. But DEXTER can't meet the test case I outlined with converting back to analogue. Sure, it outputs analogue video (it has to in order to interface with the game's monitor), but the source material it uses isn't intended to be used to recreate a physical laserdisc; its purpose is to provide something for the monitor to display.>
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.
Quote:
> Was this directed at me or Stiletto? I certainly never said this, and can't find where he did, either. It's rather confusing. >
No, this was directed to anikom15. So, dont worry.
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368053 - 07/20/17 08:45 PM
|
|
|
> Please just spare me, with your ongoing pointless one-liners. Either write a concrete > answer and be a (useful) part of the discussion, or just dont answer at all. Your > last posts regarding me, are only childish insults. If i have no clue or i am wrong > with something, try to explain it and explain it in a way that others can follow (i > cant, simply by the fact that the answer is to short and full of abbreviations.). You > only pick out stuff , where you are sure you can someone expose as a idiot. You > ignore or answer questions that are still unanswered. > > You should see, the good things in such a discussion, like the reveal of the > Domesday86 project. Something you would miss, with your arrogant attitude and > thoughts of "knowing everything".
Give me a concise list of every question you have and I'll do my best to answer them, either directly or in PM. I don't have time to wade through responses and address everything I see. I've already been a useful part of the discussion, moreso than you EVER have. I even gave four concrete options for what to do and only casm has given an answer.
|
|
|
R. Belmont |
Cuckoo for IGAvania
|
|
|
Reged: 09/21/03
|
Posts: 9717
|
Loc: ECV-197 The Orville
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: Rygar9]
#368054 - 07/20/17 08:54 PM
|
|
|
> The laserdisc is an analogue to a hard drive, so it feels to me like extending this > means that MAME should simulate the cylinders and head(s) of a hard drive, the IRQ's > generated, the ISA/PCI bus, memory controller, etc. The laserdisc player isn't really > that different from the hard drive as it is just the medium that reads out the bytes > stored on a "Storage platter".
We do currently emulate the IRQs, the ISA bus, and the memory controller (two 8237s or equivalent on an AT-compatible system). For floppy drives, we convert your favorite image formats to a series of magnetic pulses, like you'd get from a Catweasel or Kryoflux, and go from there. Why do you assume harddisks will always be higher level?
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368055 - 07/20/17 09:06 PM
|
|
|
> > Regarding converting from digital to analogue and sending that analogue signal into > the laserdisc player's laser pickup: that was a semi-serious comment, as evidenced by > the ' ' at the end of the sentence. What it meant was that if a digital copy of the > original analogue data could be converted back to analogue and played out through a > laserdisc player, then we'd have a working conversion process.> > > But the same applies to a capture. As soon as it is digital, it isnt the same like > the original anymore. The argument to be able to recreate a LD and "press" it again > is weak and nonsense, as we cant do this process anymore. 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. >
No it doesn't apply to capture. Video capture is NOT reversible, not even theoretically. It was never designed to be reversible. Can you make LD data from digital video? Yes, but you would not be making a construction of the original signal. This is because:
1. The video demodulation is imperfect 2. The comb filter changes the picture 3. Nuances in timing are completely gone 4. Phase information is distorted 5. Phases of the colorburst could be inverted 6. The equalizing pulses will not be preserved at all.
ADA conversion on the other hand is theoretically perfect so long as the signal is bandlimited (which it is). In practice there are some concerns:
1. The input needs to be properly filtered to avoid aliasing 2. Some noise is introduced (which, according to us both, is a total nonissue in this case). 3. Some phase distortion depending on the anti-aliasing filter.
And that's about it. Do you see the difference here? Do you see how capturing video removes information NOT characteristic of the video itself but is characteristic of the original medium?
|
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368059 - 07/20/17 11:05 PM
|
|
|
Mmmmh ok, that reads well... Just like some advertising catalogue from microsoft: 4k, enhanced, amazing etc. If i read all this, it sounds like capturing is a catastrophe. Mind you, it was one of the four points plan you mentioned. All the stuff you bring in, doesnt change the fact, that you marginal will see any difference (i doubt if any). Maybe you come to that thought, seeing all the captures that are done already, with hacked, ancient equipment more than a decade ago and in a wrong way. Nuances in timing? possibly, but not visible to a human eye or hearable. Regarding all the other stuff, we can philosophize. If i see how the captures where made in the past and especially how wrong the VBI data was treated, i would also say, how amazing it would be, to do conversion instead. You self wrote "is theoretically perfect", but practically it will make near zero difference, but i admit you have advertized it perfectly. The MAME LDverify tool is/was only good to see, how the different LDP-systems treat VBI data, but practically its unprofessional, in that way that no normal person can send you proper capturings, for all the reasons i wrote already. Especially treating VBI-data (which is the most important stuff) like picture-content.
I am not writing all of this to debate with you, that conversion is the best, because i agree with you in that point. My concern is, the effort you need for that conversion method vs. proper capturing vs. the outcoming result. You may have preserved the LD better, until somebody come along and say "no, 40-bit conversion is the real thing". Which in theory would be true, but visibly its nothing. I hope you realize this at least. Regarding the arcade part of the LD stuff, i ask you if you have ever seen the footage? i guess not. There are so many threads where people say the same. Have you seen "Quarter Horse" for example? Thats crappy VHS footage on a LD medium and many games are done the same way. So you can come with proper antialiasing filtering that change picture, no distorted phase information and what not, it will still look like shit, even with the best conversion process.
|
|
|
casm |
Cinematronics > *
|
|
|
Reged: 08/27/07
|
Posts: 668
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368064 - 07/21/17 12:44 AM
|
|
|
> 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.
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368066 - 07/21/17 02:15 AM
|
|
|
> Mmmmh ok, that reads well... > Just like some advertising catalogue from microsoft: 4k, enhanced, amazing etc.
These are engineering and industry terms. Not marketing terms. If you want me to explain any of the points I described please ask.
> If i read all this, it sounds like capturing is a catastrophe.
My argument is that it is not a proper method for data preservation of a specific video medium. It is a proper method for analog-to-digital video conversion. Those two goals are different.
> Mind you, it was one > of the four points plan you mentioned.
Yes, and one that I don't endorse. My hope was to get some kind of idea on what people want.
> All the stuff you bring in, doesnt change the > fact, that you marginal will see any difference (i doubt if any).
That's not the issue here. There is no perceptible difference between high quality AAC and FLAC but I'll only use FLAC or another lossless conversion method for archiving and preservation.
> Maybe you come to > that thought, seeing all the captures that are done already, with hacked, ancient > equipment more than a decade ago and in a wrong way. > Nuances in timing? possibly, but not visible to a human eye or hearable.
Two things: do you even know what timing is? and regardless human perception is not the issue here.
> Regarding > all the other stuff, we can philosophize.
I don't philosophize. This is engineering.
> If i see how the captures where made in the > past and especially how wrong the VBI data was treated, i would also say, how amazing > it would be, to do conversion instead. You self wrote "is theoretically perfect", but > practically it will make near zero difference, but i admit you have advertized it > perfectly. The MAME LDverify tool is/was only good to see, how the different > LDP-systems treat VBI data, but practically its unprofessional, in that way that no > normal person can send you proper capturings, for all the reasons i wrote already. > Especially treating VBI-data (which is the most important stuff) like > picture-content. > > I am not writing all of this to debate with you, that conversion is the best, because > i agree with you in that point. My concern is, the effort you need for that > conversion method vs. proper capturing vs. the outcoming result.
Sampling a video signal is a solved problem and won't require anymore effort from someone who knows what she is doing anymore than capturing video is for someone who knows what she is doing. The only efficiency argument here is cost.
> You may have > preserved the LD better, until somebody come along and say "no, 40-bit conversion is > the real thing". Which in theory would be true, but visibly its nothing. I hope you > realize this at least.
And I can explain to that moron about SNR, SQNR, and why there is a finite limit of bits that you can quantize at, after which you will no longer gain any more information. 10-bit is sufficient for LD composite out because the video SNR is around 50 dB.
> Regarding the arcade part of the LD stuff, i ask you if you > have ever seen the footage? i guess not. There are so many threads where people say > the same. Have you seen "Quarter Horse" for example? Thats crappy VHS footage on a LD > medium and many games are done the same way. So you can come with proper antialiasing > filtering that change picture, no distorted phase information and what not, it will > still look like shit, even with the best conversion process.
Again you fundamentally don't understand the issue of contention here. The issue is we want to preserve information stored on a Laserdisc. That means we preserve ALL the information. Not just the picture and VBI.
|
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368079 - 07/21/17 10:15 AM
|
|
|
Again: I am not writing all of this to debate with you, that conversion is the best, because i agree with you in that point and to make it clear once and for all: i do fundamentally understand the issue of contention here. You dont need to try, to make me look like a dumbnut.
If the effort is the same, than its funny how it didnt happen in a past decade, but i hope it will happen at least in the next and this thread exposed some opportunity. Capturing is a non-destructive setup (to the hardware) and a simple read me file would be enough, so that it is manageable for anyone. You can setup everything in less than a hour and it would also work with nearly any LDP.
Conversion has a potential risk of being destructive to the hardware, even for someone who knows what he is doing and the setup will differ from system to system. It can only be done by very experienced people and is a time consuming setup.
And you seriously think that the effort is the same and the only efficiency argument here is cost? Mmmmh, ok. I hope you are right, partly because the timeframe is not huge and if the bit-rot progressed to a point of no return, we will have no opportunity and ALL the information is lost forever, not just the picture and VBI (which would be enough, for a good emulation).
Edited by uman (07/21/17 10:28 AM)
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368098 - 07/22/17 04:18 AM
|
|
|
How can sampling the video signal be more destructive than capturing it? Capturing video samples the signal in the same manner. The difference is capturing follows this with processing whereas sampling just saves the data.
User-friendliness is not relevant here. Nice strawmam (or should I say uman?) argument. Regardless, it's really not hard as long as you know what you're doing. You plug the LDP composite output to a BNC adapter, plug it into the device and go.
Edited by anikom15 (07/22/17 04:22 AM)
|
|
|
smf |
I've been here before
|
|
|
Reged: 01/16/15
|
Posts: 130
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: casm]
#368102 - 07/22/17 07:47 AM
|
|
|
> The thing is that while we're both in agreement that post-read processing (passive or > otherwise) doesn't create an ideal output signal, we don't have "a while" to wait for > the ideal solution.
The ideal solution is easier to achieve and has already been implemented once, the hardware is still being manufactured & has competition to keep the cost down & can be used for other things once it's been done & so still has a resale value.
But sure, keep pushing a solution that will produce inferior results and require all the discs to be obtained again at a later date.
|
|
|
|
Re: Question about ALG driver status
[Re: smf]
#368104 - 07/22/17 08:23 AM
|
|
|
Can you link me to the specific hardware and a schematic or even just block diagram of what you want to implement?
|
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368106 - 07/22/17 10:15 AM
|
|
|
I just want to say, I really appreciate you and casm continuing to provide useful and helpful replies in this thread, because working two coding jobs while having a broken left hand, I simply haven't got the energy.
|
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368108 - 07/22/17 01:17 PM
|
|
|
> How can sampling the video signal be more destructive than capturing it? Capturing video samples the signal in the same manner. The difference is capturing follows this with processing whereas sampling just saves the data.>
Because thats what i understand from MooglyGuys manifest:
Quote:
This would effectively require tracking down a Laserdisc player with the relevant capabilities, and designing custom hardware to tap directly into the signals on the laser pickup directly after it's been sampled by the ADC and the good/no-good bit has been set or unset.
This is what is desired and this method is not just done by connecting to the composite out (on the outside case of a LDP), like you wrote. I apologize, if i didnt understand this correctly.
> User-friendliness is not relevant here. Nice strawmam (or should I say uman?) argument. Regardless, it's really not hard as long as you know what you're doing. You plug the LDP composite output to a BNC adapter, plug it into the device and go. >
I am not strawmam, strawman, not even uman. i am u-man, but registering at MW didnt allowed to use "-". But go on provoking me, monika15 (month old).
I have read and learned enough, to see that capturing is a absolute no-go. I still truly wish you all the best with your ongoing steps. It is written multiple times that the problem (setup for conversion) is solved and the effort for good data dump is the same, so i (and other LD fans) have hope, that it will happen in a near future. If there will be a option for donate, i will donate my budget for my initially intended setup.
|
|
|
casm |
Cinematronics > *
|
|
|
Reged: 08/27/07
|
Posts: 668
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368110 - 07/22/17 05:40 PM
|
|
|
> Can you link me to the specific hardware and a schematic or even just block diagram > of what you want to implement?
If I'm reading John Doe's mind correctly, I think that he's referring to this post, which in turn references this thread on the JammaPlus forums.
Fundamentally, I do agree that capturing the laserdisc output from a point as close to the laser pickup as possible before it hits the player's image processing circuitry is definitely preferable. That's really not up for question as far as I'm concerned.
However, I feel that there also needs to be a middle-ground solution. While the method that Dave Spicer used is workable, it's pretty specialised. Given that we've kicked around the possibility of using MAME as a tool for preservation of retail laserdiscs (which is a Good Thing(tm) in my book), then the solution should also be one that's accessible to someone without either the access to or interest in hardware built to capture discs at as low a level as is being proposed.
Ultimately, though, much of that will be dependent on the project's focus. I'll be the first to admit that the above paragraph is a moot point if the decision is made that only laserdiscs used with arcade and personal computer systems are of interest, and that decision subsequently determines the standards used for their capture.
With that said: time is still a factor in all of this. While I'm far from suggesting that all laserdiscs are going to spontaneously rot out overnight, there is entropy taking place and the amount of media usable as capture candidates is dwindling.
|
|
|
|
Re: Question about ALG driver status
[Re: casm]
#368111 - 07/22/17 06:07 PM
|
|
|
Thanks. That's an interesting setup but it seems like it's still dependent on a particular type of LD player. Also all that hacking about is concern for uncertainty.
The images look nice enough though. What's keeping this from moving forward?
|
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368112 - 07/22/17 06:31 PM
|
|
|
This only shows how you follow this thread, as this was previously posted here and talked about it many times.
Quote:
What's keeping this from moving forward?
I guess its finished and working, thats what at least Dave wrote. He also said, that he doesnt have much time anymore, that he can spend for his hobby.
PS: i also just want to thank everybody in this thread, not just casm or anikom15. It is a good example and revealed stuff that maybe would still be buried somewhere in the web, if there wouldnt be a talk about it.
Edited by uman (07/22/17 06:36 PM)
|
|
|
|
Re: Question about ALG driver status
[Re: uman]
#368473 - 08/01/17 04:23 PM
|
|
|
Thanks everyone for discussing it, I hope this can be implemented in some way in the near future, even if it's not 100% accurate.
If we get 90% accuracy or less, it's better than nothing. The original Nintendo GameBoy VDP for example, still hasn't been reverse enginereed, so it's still all high level guesses on how the hardware works.
I would love to help with this, but unfortunately it's way out of my technical knowledge and I lack the tools. Still, my best of luck to the team that works on this.
|
|
|
smf |
I've been here before
|
|
|
Reged: 01/16/15
|
Posts: 130
|
|
|
Send PM
|
|
|
Re: Question about ALG driver status
[Re: anikom15]
#368605 - 08/06/17 02:55 PM
|
|
|
> That's an interesting setup but it seems like it's still dependent on a > particular type of LD player. Also all that hacking about is concern for uncertainty.
Being dependent on a particular LD player is not a problem, there are only so many discs. You can be certain that if you don't hack the player, then you're not getting anywhere near an accurate representation of the data that is stored on the disc.
> What's keeping this from moving forward?
Time I think.
|
|
|
|