ld-process-efm: optionally use json data for time sync on non-timecode disks

[happycube]

Just had that idea while talking to smally about one of his decodes that lost sync. The json data might not be perfectly aligned, but is probably close enough to prevent noticable loss of lipsync.

Would be nice to have for rev7, but if everyone else is running as slow as me lately... ;P

[simoninns]

I don't really understand what's being proposed here... What JSON data and in what manner should it be used?

[happycube]

To rephrase that, since the .json file knows (or should!) how many EFM samples are output per field, it could be used as a timestamp for all the 80's disks that don't have timecodes. Then, if something gets dropped it should be able to reasonably map the output using the # of input samples read.

This would be a fallback to prevent substantial desync, since it might be off a bit even with this. Hopefully this won't actually be needed after the other audio fixes are done :)

On Sun, Nov 29, 2020 at 8:03 AM Simon Inns [email protected] wrote:

I don't really understand what's being proposed here... What JSON data and in what manner should it be used?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/happycube/ld-decode/issues/573#issuecomment-735416280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAXFCDHPXIVCFVBVPOSNDDSSJWD5ANCNFSM4UBC2GAA .

[simoninns]

Just a note for future implementation:

I think this would make more sense as an enhancement to ld-disc-mapper. Right now it does the same processing to the analogue audio file. If you want to remap the EFM based on the video metadata - that process is pretty much the same as what the audio code is already doing and wouldn't be too hard to adapt as an option EFM process.