Closed Mikewando closed 1 year ago
Before these changes, providing a decoded tbc
with perfectly sequential frames (e.g. by using ld-cut
and then ld-decode
) as input to ld-discmap
would result in a mapped-output.pcm
file smaller than the original input.pcm
file even though the disc mapping process in this case should not change the number of video or audio samples (and indeed video samples do not change).
Repeating the scenario with the changes in this PR yields a mapped-output.pcm
file which is identical to the input.pcm
file.
As the existing comment notes, the previous field's start and length should be used to determine the current field's start. Otherwise we may use the wrong offset.
Furthermore the maps for start and length are 0 indexed, but input sequential frame numbers are 1 indexed and should be corrected.
With the map correction it is also now possible for ld-discmap to actually try to read the last field's audio data, which is likely to be the end of the pcm file. Attempting to read the pcm input file completely would not append the last sample and would result in the program crashing. Updated this to be a warning (to avoid crash) while still appending the data since it's valid.