Description: Fixing a bug likely introduced when doing the bytevector refactoring. Discovered when trying to mess around with one of my files that contained an (unknown to me) GEOB frame. The GEOB frame contained a cue points table, likely stored by rekordcloud. The frame was encoded in Latin1 encoding, which means the GEOB frame starts with 0x00. The attachment frame parser starts by looking for 0x00 to determine the end of the mime type. If the frame is encoded in Latin1, the parser will think the mime type is 0 bytes long, leading to a failure. The fix is to introduce an offset in searching for mime type delimiter.
Testing:
Added a test to verify the behavior of GEOB when encoded with Latin1
Description: Fixing a bug likely introduced when doing the bytevector refactoring. Discovered when trying to mess around with one of my files that contained an (unknown to me) GEOB frame. The GEOB frame contained a cue points table, likely stored by rekordcloud. The frame was encoded in Latin1 encoding, which means the GEOB frame starts with
0x00. The attachment frame parser starts by looking for0x00to determine the end of the mime type. If the frame is encoded in Latin1, the parser will think the mime type is 0 bytes long, leading to a failure. The fix is to introduce an offset in searching for mime type delimiter.Testing: