It is currently 20 Feb 2019, 16:38




 Page 22 of 23 [ 441 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23  Next
Author Message
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 28 Jun 2018, 14:06 
Honest fan
Honest fan
User avatar

Joined: 11 Sep 2017, 14:24
Posts: 82
Location: Sweden
Has thanked: 1 time
Been thanked: 34 times
Glad you like the new revision :) I've tested the board up to 75MSPS now and it has no problem moving the bandwidth; so I pretty certain the design could be re-purposed for other things. You should be able to use just the DE0-Nano and USB 3 if you don't need ADC - however; the front-end design may be non-trivial if you need it to work with anything other than 3.3V.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 30 Jun 2018, 14:22 
Shows curiousity
Shows curiousity
User avatar

Joined: 18 Jul 2016, 05:18
Posts: 28
Location: Australia
Has thanked: 0 time
Been thanked: 7 times
Ok, I've had this on the shelf for the past month, but it's time to get back to it. I'm determined to solve this phase lock problem I have with the colour burst. Simoni, a month or so ago you said this:
simoni wrote:
Nemesis wrote:
I'm going to keep hammering away at this, but I believe capturing at a higher sample rate would help a lot.


This can't be the case ;) Laserdisc players can do it with half the sampling speed, vis-à-vis, so can you :) I looked into this quite a bit and came up with the conclusion that the only sure-fire way was to do it is by using a ADPLL implementation (All Digital Phase Locked Loop). When I looked at the best way to achieve a constant sub-sample timing measurement (which was resistant to error and jitter), everything pointed to this. Trying to do it in a 'deterministic' fashion (like ld-decode does at the moment) will never get the consistent results that a PLL would. Trouble is, I couldn't for the life of me figure out how to code it. I even paid for a copy of Phase Locked Loops by Roland E. Best and just ended up in a flat-spin around the maths involved. DSP coding isn't really my forte! (I can do FPGA, embedded C and desktop C++ though, so I won't beat myself up over it ;) )

You seem to have a better grip of signal processing software than myself though; so perhaps my insight will give you an idea (even if I'm horribly wrong!).

I've done some reading on phase locked loops, and to be honest, I don't think what I'm doing is too far off the mark, but I'm realising I may be making some incorrect assumptions about the LaserDisk signals themselves and making things harder for myself. I notice the concept of a PLL is to take a long sampling of the input data over time, and use that information to estimate the true frequency and phase. I thought I couldn't do that accurately between lines, because I was worried about TBC (time base correction). Right now, my impression of the analog input signal I'm getting is that it could be randomly stretched or compressed anywhere, meaning I need to find the precise line start and end times during TBC, and pull them back into alignment. The most accurate way I've found so far to perform TBC is actually to use the phase of the colour burst signal as a guide. I use the hsync rise and fall to get close, but I refine it by comparing the colour burst sync between lines. When I added that step, I seemed to get much better results. We only get about 9 full colour burst wave oscillations per line though, and I've found the first and last 1-2 of those to be questionable at best on most signals I've observed. That's simply not enough samples to get an accurate phase lock from a single line. It's close, but not close enough. If I can't trust I have perfect sync between lines though, as my signal could have been randomly compressed or stretched, how can I use the colour burst samples from the following line to correct my phase lock? I could just ignore this problem and try and pull in samples across the entire field, or even successive fields, to error correct my colour burst frequency and phase, but this seems inherently flawed, as I don't expect my TBC can possibly be more accurate than my phase lock. I've estimated the line sync based on the estimated colour burst frequency and phase already, but if my initial estimated phase lock to the colour burst is off, how can I now estimate my colour burst frequency over lines, when I know I synced the lines based on my initially estimated phase? It kinda feels like a chicken and egg problem. I can't accurately sync my lines without a phase lock, and I can't get a phase lock without accurately synced lines.

Am I way off base here? is there something different I should be doing about TBC, or am I wrong about my assumptions on how the analog input stream can be distorted? The colour burst signal is potentially distorted, isn't it? I know there's no way known the real hardware can phase lock the colour burst from a single line, so it must be possible to use successive lines and frames somehow. If I could trust the input signal was in perfect time to start with, I could just extrapolate across many lines to find the frequency and phase that best fits the curve running between them, but where does TBC fit in? How can I get "perfect" TBC, before phase locking the colour burst? Any suggestions, or light reading material I could refer to?
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 03 Jul 2018, 06:56 
Honest fan
Honest fan
User avatar

Joined: 11 Sep 2017, 14:24
Posts: 82
Location: Sweden
Has thanked: 1 time
Been thanked: 34 times
The PLL is used because otherwise you are assuming a perfect system. In an ideal world you'd be expecting a video sync every X ms and any variance from the expected delay is 'jitter'. In reality, there is no guarantee that the player's mechanics are that accurate. X-1 might be right for one player/disc and X+2 for the next due to the tolerances on the RPM control of the spindle motor (and the variance from that is the actual jitter). It's important to follow the 'natural' timing of the disc if you loose the sync signal otherwise you will be compensating for a timing which is arbitrary rather than the actual expected sync delay for the disc. In my mind this is where a PLL is advantageous as it will continue to output the correct sync timing for the disc even in the event of sync loss (and such output is specific to the disc and player environment at the time of loss).

I'm just guessing though :) Happycube is probably the right person to provide advice around this. I know he's also working on newer TBC code that is extremely tolerant even to badly rotted discs.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 04 Jul 2018, 18:01 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
I use multiple types of low pass filtering to perform TBC:

- rough sync: A .5mhz LPF is itself clipped to true/false based on signal level then low passed. From this a clear pattern of both horizontal and vertical sync can be observed, and rough line sync can be achieved.
- finer sync: The .5mhz LPF is then looked at directly to determine where the line sync ends. This is generally quite accurate.
- color burst: This isn't working right yet on really bad disks (which might be beyond hope really...), but I'm running the burst through an IIR-type low pass filter, and computing phase based off the strongest bit of that filter.

And if spikes outside of the expected range are detected, it gives up and uses the previous lines' length and hopes for the best...

I've got a new notebook at https://github.com/happycube/ld-decode/ ... -dev.ipynb that uses all this, and I'll slowly add comments and clean it up hopefully. (There are a few glitches to fix with my GGV1001 12" reference disk captures for instance...)

The latest code also has phase compensation for the DD 3.0 board, which improves sharpness and color burst level and quality considerably. I'm going to have to move to 8x FSC comb filter processing (double the horizontal # of pixels used in digital TBC players) to get the full benefit of that ;)
_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 10 Jul 2018, 17:37 
Third post and above
Third post and above
User avatar

Joined: 06 Feb 2011, 05:47
Posts: 5
Location: United States
Has thanked: 0 time
Been thanked: 0 time
Wow, I’ve been away from this thread for about a year due to a dead LD player. I was just going to check in to see if there had been any updates... :shock:

Simon, I’m curious if you’re PLayer integrated capture setup might work with any other industrial players. I have an LD-V8000 that I’d like to use.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 10 Jul 2018, 17:48 
Shows curiousity
Shows curiousity
User avatar

Joined: 20 Jan 2010, 23:33
Posts: 21
Location: United Kingdom
Has thanked: 14 times
Been thanked: 0 time
Hi schorman,

As long as it uses the same serial protocol as the LD-V4300D then it should be OK. I know Happycube is using a different player and simon fixed some issues with Baud rate being different and some small changes to fix a few issues.

If you can I would join our facebook group as there is more of a running commentary with sample video frames for review and updated more often than here.
https://www.facebook.com/groups/2070493199906024/

Regards

Ian
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 11 Jul 2018, 18:58 
Third post and above
Third post and above
User avatar

Joined: 06 Feb 2011, 05:47
Posts: 5
Location: United States
Has thanked: 0 time
Been thanked: 0 time
Thanks for the suggestion. I’ve been off of FB for over two years and this is the first even remotely good reason I’ve found for rejoining. I’m just trying to work up the courage to try soldering my own 3_0 board at this point.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 19 Jul 2018, 20:30 
Second post
Second post
User avatar

Joined: 26 May 2017, 16:08
Posts: 2
Location: France
Has thanked: 0 time
Been thanked: 0 time
Topic subscribed and bookmarked.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 26 Dec 2018, 04:02 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
Most of the discussion is on the #domesday86 freenode channel now, along with the FB group, so while this thread's been silent there's still been plenty of good progress :)

New software release (rev3) today, which includes Simon's tools.

PAL quality is greatly improved: https://www.youtube.com/watch?v=qH0jnMLEJ64 is a 1-minute Domesday intro. Really pushing what the source material: a PDO UK disk from 1986... at the beginning of a CAV disk where higher frequencies are truncated. A MUSE PAL player would really help here, but they don't exist.

_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 02 Jan 2019, 04:42 
Shows curiousity
Shows curiousity
User avatar

Joined: 18 Jul 2016, 05:18
Posts: 28
Location: Australia
Has thanked: 0 time
Been thanked: 7 times
Hello all. I've been wrapped up in other things for the last 8 months or so, but I'm coming back around to this project again. I've built myself a Domesday Duplicator 3.0 board which is working nicely, and I've got an LD-V8000 player with serial communication working to the software. I'm able to capture good rips easily from the hardware, so that's great. I'm still finding the software decoding experience to be problematic though. Decoding still seems extremely slow, and frame detection seems hit and miss on signals I've tried. With recent changes to the ld-decode software, it also seems harder to work with straight composite video input from other sources, which is something I'm very interested in, not just straight Laserdisc decoding.

I'm keen to have another shot at doing my own video decoding. I had a decoder working previously for straight composite NTSC video, and it had really fast, good frame detection that worked even with crazy things like mixed-mode video signals where it changes from progressive to composite, and has timing that's off-spec. The main thing this needed was work on a proper digital PLL to accurately sync the line start times, as that wasn't accurate enough and it was affecting colour decoding in particular. I know what I need to do there to fix things. I want to try and bite off the first level of the problem this time though, and do my own demodulation from the raw RF Laserdisc signals. This is the part that seems slowest by far right now in the ld-decode software chain. Since it's done using a single-threaded implementation in python, I think a multithreaded implementation in C++ should be able to get a much faster result. I'm a bit stumped on the math though, and I can't figure out enough of the specifics from the ld-decode repository though, so I was wondering if I could get a bit of help.

Here's where I'm up to. I get that multiple signals are combined into one RF signal, by frequency modulating them into particular frequency ranges. I have the Laserdisc spec that describes it all, and the Laserdisc decoding guide on Domesday86 has a great summary. I can observe the signals together in a basic spectral view of the raw RF, like so:
Image
Here I can clearly see the composite video signal encoded, in this case showing the end of a field, the vblank period, and the start of a new field. I can see the two analog audio channels encoded below, and at the bottom, a band of low-frequency noise which contains the digital audio channel data. I can also see the harmonic sidebands coming through, giving lower intensity "echoes" of the data at lower and higher frequencies than the encoded frequency. When the composite video is decoded to a waveform, I expect to see a signal like this:
Image
The problem I'm having right now is, I don't really understand the math involved in demodulating the FM signals from the combined RF signal here. I understand I can use some basic band-pass filtering to eliminate frequencies outside the bands I'm interested in, which would allow me to "strip out" audio signals from each other and from the video signal, but after that it's the actual process of de-modulating the FM-encoded data back into their data streams (IE, turning FM encoded data back to an AM waveform), that I'm not getting right now. I can see from the ld-decode source it's something to do with FFTs and a so-called "Hilbert transform", but I don't want to blindly cut and paste what's been done there, I want to understand what I'm actually doing to get the signal out and why it works, and I've struggled to find a good explanation online so far. Can anyone break down an RF demodulation 101 guide for me, or point me to a good resource that'll describe this in simple terms, IE, something other than a 45 page pure math proof? I need to understand enough about this process to be sure I'm making sensible choices about the decoding process, and the way I "tune" the filtering steps in particular. Any advice is appreciated.
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 02 Jan 2019, 17:58 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
Unfortunately I don't really have the time/mental energy to give this a great quality response. The best reference I currently have is the code, alas. I know comments are an issue and opened https://github.com/happycube/ld-decode/issues/77 a weekish ago, please ask questions there and I'll add comments and de-cruft the code where I can.

- I got the idea for the Hilbert transform from a Pioneer patent about using digital decoding for Laserdiscs, US4736238. Sadly such things are probably harder to read than 45 page math proofs. :P

- The FFT is a way to stack all the filters used in one 'phase' into one operation. In the frequency domain filters are commutative. It also has the (currently unused) advantage of being GPU-friendly.

- For the TBC, thanks to Simon giving me a pointer to a Tektronix doc (https://www.tek.com/document/primer/tel ... sc-systems) I found that the burst phase is (meant to be) aligned with the 50% point of the downslope going into HSYNC. It should be as close to 0 degrees off as possible, with 45 max and 90 right out. Of course this means one disk did just that ;) So my current code is a bodge to deal with that and I'm refactoring it.

But basically you can use the timing of the start of HSYNC, combined with 0IRE crossings of the burst, to determine line position at any input frequency and downscale from there.

- The development branch (rev4) has some cleanups to do with framing/field ordering, there's a bug fix or two I need to backport to master, I just don't have time this morning and it might touch on Simon's code, so it might not happen until rev4 is merged.
_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 08 Jan 2019, 07:16 
Shows curiousity
Shows curiousity
User avatar

Joined: 18 Jul 2016, 05:18
Posts: 28
Location: Australia
Has thanked: 0 time
Been thanked: 7 times
I've been making some headway on implementing my own RF decoding, but I was wondering if I could pick your brains about filtering for a few minutes. While pulling apart an old version of ld-decode.py, I noticed the filtering code seems to be producing artifacts on the edges of the chunks you process the file in. Here's a snapshot of the video signal for example before filtering:
Image

And here's the result after it's run through just the first stage of filtering in ld-decode.py (Bbpf, Bcutl, and Bcutr):
Image

Those artifacts seem to have a significant effect on the output signal. Is this something you're aware of, and have corrected in later versions? I've also got questions about the filtering technique itself. While you went for a series of bandpass and bandstop filters, I opted for a single highpass filter as a pre-processing step, which gave me the following:
Image
This seems to be more effective in discarding the low frequency values. Do you have any thoughts on a high-pass filter approach here, as opposed to targeted bandpass and bandstop filters?

In terms of the later stages, I've got hilbert transformation working, and I'm getting a reasonable result from demodulation, but the de-emphasis filtering step is confusing. From the comments in your code, I gather you've had trouble with this stage too. Do you have any advice or insights to share about this step? Do you have access to the IEC 60857 Laserdisc standard, or any other resources that discuss this in detail?
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 08 Jan 2019, 09:02 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
The block edges are cut out after demodulation, so they shouldn't affect the output. A more fancy approach would be to do a proper overlap/add FFT technique.

The filters were based off what LD players actually did... using a filter that's too strong can change how the signal is decoded (i.e. adding ringing, etc) A stronger high-pass filter might work better, but the unfiltered top end frequencies may result in additional noise. For the Domesday Duplicator caps pretty much everything over 13.5mhz on a CLV/low-frame# CAV disk simply isn't disk data.

de-emphasis is confusing and there aren't really any documents that go into it in detail. LD player schematics and tech references are about the best sources out there.
_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 29 Jan 2019, 06:48 
First post
First post
User avatar

Joined: 29 Jan 2019, 06:42
Posts: 1
Location: Russian Federation
Has thanked: 0 time
Been thanked: 0 time
Hi from Russia! :roll:
Monitoring this thread i can't find witch pioneer i need for ripping?
Now i got Pioneer LD-V8000, but dead laser.. (PS m.b. someone know is there any chance to buy it or just find working LD-V8000?)
I understand correctly that I need only pioneer with RS-232 port? :?:
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 03 Feb 2019, 22:54 
Third post and above
Third post and above
User avatar

Joined: 08 Feb 2007, 17:24
Posts: 7
Location: United Kingdom
Has thanked: 1 time
Been thanked: 0 time
wondras wrote:
A few other interesting players I hope to try: [...] LDP-3600D (NTSC/PAL)


Did you ever get anywhere with that? I've had my LDP-3600D apart today to fix an intermittent audio connector, and noticed that there are a couple of multiway connectors on the RF board that are easily accessible from the door on the back panel - I'm wondering if there's an RF output somewhere in there...

(For that matter, does anyone have a service manual for the LDP-3600D?)
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 06 Feb 2019, 05:04 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
@ryanclow - Almost any Pioneer LD player will work. The later ones are probably easier, since they have a set pattern for the RF tap point along with other test lines. You don't really need serial control, it's just nice to have. For some types of disks with lots of picture stops, the "picture stop cancel" function is more important, since then you can play through the whole disk without interruptions.

Also, rev4 is up, simoni did this promo video: https://www.youtube.com/watch?v=aNAwMmWLFTs
_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 06 Feb 2019, 21:32 
Honest fan
Honest fan
User avatar

Joined: 12 Sep 2015, 05:57
Posts: 68
Location: United States
Has thanked: 1 time
Been thanked: 1 time
happycube and simoni, those 2 last youtube video posts look amazing, congrats!
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 15 Feb 2019, 18:56 
Knows how to post
Knows how to post
User avatar

Joined: 06 Aug 2014, 14:54
Posts: 9
Location: United States
Has thanked: 0 time
Been thanked: 0 time
Hey everyone! I’ve been really excited to follow this project, and am both incredibly thrilled & grateful for all your efforts and progress so far. I had a thought, so I figured I’d ask here, my apologies if this has been brought up already though…


It’s been said that the early gas-laser players or “red laser” players have a superior pickup that are better at reading what’s actually on the disc, providing better s/n and are better at rejecting noise, rot or damage on the disc’s surface. It’s been said they’re the best players for difficult to read discs, like Discovision releases and things like that


Of course since those older players are missing pretty much any of the modern conveniences or features that would be common to something made 20 years later, I think they’re generally considered undesirable as a day-to-day playback device. Not to mention somewhat unreliable.


All that said… if there’s a way to tap the RF off one of these vintage players, is there a possibility that they may theoretically give a better RF capture than a more common/modern player is capable of, especially with problem discs? Is there even any truth to the whole “red laser” thing in the first place?
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 16 Feb 2019, 04:25 
Hardcore fan
Hardcore fan
User avatar

Joined: 18 Apr 2012, 18:02
Posts: 1480
Location: United States
Has thanked: 26 times
Been thanked: 21 times
Thanks!

It's just the MUSE players that have wider frequency response - the gas tube players have a lower Numerical Aperture lens, which makes it easier for them to focus.

I find the last CLD design does quite well tracking all but the very worst Discovision disks, although a gas tube or MUSE player could do better playing them.

Warren has this summary of various LD players: https://docs.google.com/spreadsheets/d/ ... 1956776091

The best one was a LD-V1000 he was borrowing that was all but new old stock. Note that it is the same basic design as the PR-8210 and the LD-1100, so adjustment does play a huge role. And that model only plays CAV...
_________________
Happycube Labs: Where the past is being re-made, today. [meep!]
Offline
 Profile  
 
 Post subject: Re: (WIP) Laserdisc software image decoder from raw signal
PostPosted: 16 Feb 2019, 04:30 
Jedi Master
Jedi Master
User avatar

Joined: 03 May 2004, 19:05
Posts: 5246
Location: United States
Has thanked: 30 times
Been thanked: 67 times
Another note: I was told that if the gas lasers need to be aligned one needs to adjust the mirrors and you must have special jigs or something like that to get the
angles correct.
Online
 Profile  
 
Display posts from previous:  Sort by  
 Page 22 of 23 [ 441 posts ]  Go to page Previous  1 ... 19, 20, 21, 22, 23  Next


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to: