ID3v2: fallback when BOM is not present in UTF-16 data#614
ID3v2: fallback when BOM is not present in UTF-16 data#614Serial-ATA merged 1 commit intoSerial-ATA:mainfrom
Conversation
aschey
changed the title
| let endianness: Option<fn([u8; 2]) -> u16> = if encoding == TextEncoding::UTF16 { | ||
| match bom { | ||
| [0xFF, 0xFE] => Some(u16::from_le_bytes), | ||
| [0xFE, 0xFF] => Some(u16::from_be_bytes), | ||
| _ => None, | ||
| } | ||
| } else { | ||
| None | ||
| }; |
There was a problem hiding this comment.
Do you have an example with a broken language frame? Not sure I understand what the solution here is. decode_text with an encoding of UTF16 should fail anyway if there isn't a valid BOM.
There was a problem hiding this comment.
Sure, here's one that reproduces the problem. The frame does decode correctly with this change in place. I don't know much about id3 tags so maybe this is just a band-aid fix, but I was trying to preserve the behavior from 0.22 where this worked previously.
04 Blood on the Radio.zip - the lyrics tag is the one that fails here without this change
There was a problem hiding this comment.
Ah, yeah. #535 broke the case of empty descriptions which shouldn't have a BOM. This change makes sense then, I'll just update the comment
Co-authored-by: Serial <69764315+serial-ata@users.noreply.github.com>
Serial-ATA
force-pushed
the
fix/bom-error
branch
from
59ae416 to
1e6a11a
Compare
|
Thanks! |
2 participants
Resolves #613
This restores the behavior prior to #535 where language frames are still parsed successfully if the BOM is not present in UTF-16 data. I don't have any files that cause an issue here with text frames, but I updated it there too for consistently. I can revert that if desired.