search

happycube / ld-decode

Software defined LaserDisc decoder
GNU General Public License v3.0
304 stars 80 forks source link

EFM data alignment with TBC output #549

Open simoninns opened 4 years ago

simoninns commented 4 years ago

For analogue audio there is a metadata item which states the number of samples (in the .pcm) associated with the fields contained in the .tbc. This allows tools such as ld-discmap to track and align analogue audio when processing the TBC (to keep everything in sync). Such alignment is also key for 'stacking'.

There is no such item in the metadata for the EFM - perhaps there should be? Something like the number of associated T-values or some other trackable amount? This would allow error correction at the very early stages of EFM decoding when multiple sources are available.

happycube commented 4 years ago

I don't think it's currently tracking the .efm output that closely - ld-decode does the prefiltering and then pipes it off to the efm decoder, which is then piped into the .efm file - that processing can occur after the rest of the TBC field is output even.

simoninns commented 4 years ago

This is probably a good indication that the current implementation is wrong :) We should probably think about reverting to a set up where ld-decode isolates the EFM only and then (via the metadata) frames it to align with the TBC. Then the PLL and such is done in the tool chain. Otherwise there is no way to discmap (or stack) EFM, so there will be no way to deal with EFM data that isn't timestamped (as there is no alternative to correct it otherwise).

happycube commented 4 years ago

That takes up a lot more disk space, so it's probably best to keep it an option IMO. I can see where it would be very useful for stacking though!

simoninns commented 4 years ago

Not sure disc space is the priority vs recovering EFM data... but making it optional would be good to begin with as it would smooth the transition to updated tools.

happycube commented 4 years ago

Considering efm_pll is currently 40msps but doesn't need to be, it's a [i]lot[/i] of disk space.

However, it's not done as a background task as it probably should be, so it's actually very easy to get the # of T-values. Just checked it into the issue459 branch.