LoadLDF random-access seek uses incorrect timestamp scaling

[JoeyLemur]

Bug Description

LoadLDF random-access reads can return data from the wrong capture location.

The regression was introduced in 5497367a. Its bundled LoadLDF change divides seek positions by 1,000 and multiplies decoded PTS values by 1,000.

For FLAC LDFs, PTS already counts stored samples. container.seek() is called without stream=, so its offset must be expressed in av.time_base units.

Steps to Reproduce

1. Checked out main at 8af0932
2. ld-decode --start 437 --length 5 michael_collins_s3.flac.ldf output

Expected Behaviour

Should decode the initial CAV frames (including frame IDs 1–3). This is the behaviour in v7.2.1.

Actual Behaviour

Decodes frames 437–441 as CAV lead-in rather than the expected CAV frames.

Environment

• ld-decode version: main at 8af0932
• Operating System: macOS
• Hardware Used: Apple Silicon

Additional Information

The preceding commit, 8d098b8, produces the expected result; 5497367 is the first commit where this shows up.
Removing only 5497367’s DemodCache wait hunk does not affect the failure. Restoring only the previous LoadLDF seek and PTS conversions fixes it:

seek_seconds = sample / self._stream.sample_rate
seek_time = int(max(0, seek_seconds - 1) * av.time_base)
self._container.seek(seek_time, any_frame=True)

base_sample = round(
    float(frame.pts * self._stream.time_base) * self._stream.sample_rate
)

Issue was filed with AI assistance, but human meatware rewrites.