false report of file truncation, when padding byte is not null but not 1st byte of a chunk id

[dericed]

Thx for @privatezero for finding this error. He has several ProTools files using 24 bit mono (so odd-length padded data chunks are expected). There is a padding byte present; however it is not a null byte.

When opened, BWF MetaEdit gives a padding error which is correct.
When I select, accept with padding error, then the next chunk (using the example wav below) is "QLIS" (rather than "LIST") and the size is "0x1a54" rather than "0x1a", so the file reports as truncated.

When the chunk size is odd and the padding byte is not null, I think we need a test of the subsequent chunk structure to see if the byte in the padding byte position is the first byte of the subsequent chunk id or not. If this case the chunks after the padding byte are valid however reading at the padding byte position creates an impression that the file is invalid. I haven't examined the audio in this case to know if the fix here is to increase the size of the data chunk by one byte (which would make the padding byte as an audio sample) or to overwrite the present padding byte (here 0x51) with a null byte.

52 49 46 46 6A 00 00 00 57 41 56 45 66 6D 74 20 28 00 00 00 FE FF 01 00 44 AC 00 00 CC 04 02 00 03 00 18 00 16 00 18 00 04 00 00 00 01 00 00 00 00 00 10 00 80 00 00 AA 00 38 9B 71 64 61 74 61 0B 00 00 00 00 00 00 00 00 00 00 00 00 00 00 51 4C 49 53 54 1A 00 00 00 49 4E 46 4F 49 43 4D 54 0E 00 00 00 50 61 64 64 69 6E 67 20 42 79 74 65 2E 00