Previous Thread
Next Thread
Print Thread
#123165 02/04/24 04:41 PM
Joined: Nov 2006
Posts: 23
D
Member
OP Offline
Member
D
Joined: Nov 2006
Posts: 23
With all the resurgence in laserdisc interest, and the distribution of LDF and TBC files, I was wondering about the process of going from those files to CHD.
Given there are probably a few of us with hardware able to do the decodes even if we don't have the player or other hardware, knowing the process would be nice from that perspective.

Is there any tutorial or guide to best settings for making the source AVIs for the CHD - I presume we still need lossless AVIs for this, but I've struggled to find anywhere that's authoritative on what the format should be, what output from the chroma decoder is needed in terms of number of VBI lines, progressive/interlaced and even things like the correct colour space post decode.

There are some bits of information at the ld-decode and vhs-decode wikis but they seem more concerned with stripping the VBI and providing a more Youtube-friendly lossy encode than the MAME definition of archival, it seems.

Joined: May 2009
Posts: 2,208
Likes: 354
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,208
Likes: 354
For decoding, this assumes well-captured LDFs (no observed player skips while capturing, capture looks to be about 40-50 gigabytes in size):

1. Gather a set of LDF files. You usually want anywhere from 5 to 10 discs to capture, from the same pressing of the disc. This will allow them to be stacked, with the hope of hitting a stacked capture that has zero areas automatically marked as "dropout'. Let's call these captures dl1.ldf through dl5.ldf.

2. Decode the LDF files into TBCs. Depending on the exact toolchain you're using - Oyvind's compile for Windows, or the native Linux version - you'll do either:
Code
ld-decode -t X -s S <path and name for input TBC> <path and name for output files>

or

decode ld -t X -s S <path and name for input TBC> <path and name for output files>

In both cases, X is the number of threads to use when decoding, and S is the number of frames to start into the file. You usually want to start the decode with a few frames of lead-in before going into sequential picture numbers. Having too much of the player seeking around before the actual start of the capture can throw off the disc-mapping process.

3. Pre-process the VBI data for the ld-decode toolchain's purposes:
ld-process-vbi <path and name for input TBC>

4. Spend a much more time mapping each disc:
ld-discmap <path and name for input TBC> <path and name for mapped TBC>

If the initial scan aborts early, try running with the -s option to make it less picky with NTSC pull-down content. In the worst-case scenario, you can also try -r to reverse the field order, but that should only be used if you know exactly what you're doing, and have been decoding discs for a while.

5. Load each mapped capture into ld-analyse and make sure they look sane. Make sure the same fields appear on the same picture numbers across the mapped captures.

6. Stack them:
ld-disc-stacker <path and name for first input TBC> ... <path and name for last input TBC> <path and name for output TBC>

7. Look at the PCM files in a wave editor of your choice. Choose the one that has the best quality - PCM stacking isn't yet a thing.

8. Create your raw AVI:
ld-chroma-decoder <path and name of stacked TBC> -qf ntsc2d --ffll 1 --ffrl 1 --pad 1 - | ffmpeg -f rawvideo -r 30000/1001 -pix_fmt rgb48 -s 760x524 -i - -f s16le -r 44.1k -ac 2 -i <path and name of best PCM file> -vcodec huffyuv -pix_fmt yuv422p -acodec pcm_s16le output.interlaced.avi -y

9. Put the active video into a separate container:
ffmpeg -i output.interlaced.avi -vcodec huffyuv -pix_fmt yuv422p -acodec copy -vf "crop=760:480:0:44" output.interlaced.active.avi -y

10. Crop the VBI area of the video into a separate container:
ffmpeg -i output.interlaced.avi -vcodec huffyuv -pix_fmt yuv422p -an -vf "crop=760:41:0:0" output.vbi.avi -y

11. Pad in an additional three lines, as the VBI lines are not really intended to be visible in the video output, but I added that functionality to ld-chroma-decoder for MAME purposes. So it is a bit of an afterthought.
ffmpeg -i output.vbi.avi -vcodec huffyuv -pix_fmt yuv422p -an -vf "pad=760:44:0:3" output.vbi.padded.avi -y

12. Put the adjusted VBI and active video together again:
ffmpeg -i output.vbi.padded.avi -i output.interlaced.active.avi -vcodec huffyuv -pix_fmt yuv422p -acodec copy -filter_complex "vstack=inputs=2" output.fixedvbi.avi -y

13. Scale it to the expected 720x524 framing expected by MAME. This could be extended in a future CHD update.
ffmpeg -i output.fixedvbi.avi -vcodec huffyuv -pix_fmt yuv422p -acodec copy -vf "scale=720:524,setsar=1:1" output.avi -y

14. Create the CHD using chdman. This part requires a bit of finesse. When you were dealing with ffmpeg up above, take note of the total number of video fields that end up being processed, subtract 20 from it, then use that frame count here:
chdman createld -i <output AVI> -if <frame count> -o <output CHD name>

If compressing with chdman fails, take whatever you used for "frame count", subtract another 20, and try again. If it succeeds, add 10, and try again. Use this to narrow down the exact number of frames that can be encoded.

There's some slight drift due to AVI not handling an uneven number of samples per field well, which is also something that will eventually be addressed.

Joined: Nov 2006
Posts: 23
D
Member
OP Offline
Member
D
Joined: Nov 2006
Posts: 23
That's brilliant, thanks so much. Between this and what is out there for PAL discs because of Domesday favouring those for their own ends, I think that covers everything. My intention is to try to do some experimentation in PAL for MAME thanks to the Marbella Vice release, but given your warnings about chdman taking a fixed resolution, with the VBI being slightly different in that space, I guess it may be more effort to ultimately put this into a workable form.

Anyway, thanks again for the information, I'm sure it'll be a useful resource.

Last edited by elcondor; 02/04/24 07:46 PM. Reason: PAL notes
Joined: May 2009
Posts: 2,208
Likes: 354
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,208
Likes: 354
Sure, but be aware that PAL LD games are something that haven't been tested in MAME. It's why I keep asking Robbie to get me hooked up with the Marbella Vice TBCs, so I can play around with making the output process as close to the current NTSC one as possible - but two weeks and radio silence so far.

Joined: Nov 2006
Posts: 23
D
Member
OP Offline
Member
D
Joined: Nov 2006
Posts: 23
The stacked TBC is out there (3 discs, and 'theoretically' dropout free), but I guess that's too pre-processed for your toolchain - someone in the Amiga scene pointed it out to me, as they knew I had a jones for the ALG games back in the day. Not sure what the rules are on link sharing, but my PMs are open if you do want it.

Joined: May 2009
Posts: 2,208
Likes: 354
J
Very Senior Member
Offline
Very Senior Member
J
Joined: May 2009
Posts: 2,208
Likes: 354
No, if the stacked TBC, the stacked JSON, and a well-chosen PCM file are out there, there's enough to get a decode into MAME.

Joined: Nov 2006
Posts: 23
D
Member
OP Offline
Member
D
Joined: Nov 2006
Posts: 23
PM sent, then. Don't think this is MAMEable for a long stretch though given everything


Link Copied to Clipboard
Who's Online Now
3 members (AJR, Dorando, belegdol), 48 guests, and 1 robot.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,308
Posts121,697
Members5,070
Most Online1,283
Dec 21st, 2022
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com