When an ID3v2 text frame contains malformed UTF-16 content (e.g. odd byte length), lofty surfaces an error like: Text decoding: UTF-16 string has an odd length
I'm not very familiar with Rust, but I think the frame ID is available in parse_frame (in src/id3/v2/frame/read.rs) when parse_content fails, but is dropped by the ? operator:
fn parse_frame<R: Read>(
reader: &mut R,
size: u32,
id: FrameId<'static>,
...
) -> Result<ParsedFrame<'static>> {
match parse_content(reader, id, flags, version, parse_mode)? { // id lost on error
The fix might be something like adding context to the error before propagating:
parse_content(reader, id.clone(), flags, version, parse_mode)
.map_err(|e| e.context(format!("In frame '{}'", id)))?
This would produce a message like:
Text decoding: UTF-16 string has an odd length (in frame 'TIT2')
..which makes it much easier for applications and end users to identify and fix the problematic tag without having to reimplement raw ID3 byte scanning themselves.
When an ID3v2 text frame contains malformed UTF-16 content (e.g. odd byte length), lofty surfaces an error like:
Text decoding: UTF-16 string has an odd lengthI'm not very familiar with Rust, but I think the frame ID is available in
parse_frame(insrc/id3/v2/frame/read.rs) when parse_content fails, but is dropped by the?operator:The fix might be something like adding context to the error before propagating:
This would produce a message like:
Text decoding: UTF-16 string has an odd length (in frame 'TIT2')..which makes it much easier for applications and end users to identify and fix the problematic tag without having to reimplement raw ID3 byte scanning themselves.