Fix pcmAudioField map contents and access

[Mikewando]

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.

[Mikewando]

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.