Wav: Failed to read RIFF INFO item value

[Ferry-200]

Reproducer

I tried this code:

let tagged_file: Option<TaggedFile> = match lofty::read_from_path(
        "C:\\Users\\ferry\\Music\\test\\大哉乾元(洛天依人声版)_MMM.wav",
    ) {
        Ok(value) => Some(value),
        Err(err) => {
            // Wav: Failed to read RIFF INFO item value
            println!("{}", err);
            None
        }
    };

The lofty version is "0.18.2"

Summary

There is an error "Wav: Failed to read RIFF INFO item value"

The Windows Properties page can read the tags in it. I can also play it on Windows Media Player.

Can anyone provide some information about this? Thanks.

Expected behavior

Read tag correctly.

Assets

大哉乾元(洛天依人声版)_MMM.wav

[Serial-ATA]

Hello!

Your file has items that are not UTF-8 encoded. What is your local character encoding? If Windows is able to read it, that means the file is using your system encoding.

[Ferry-200]

UTF-16.
And the file's tags are UTF-16 LE encoded.

[Serial-ATA]

Hm. It's unfortunate that RIFF doesn't specify a text encoding. We would be able to somewhat reliably detect UTF-16 LE, but there's no BOM either. The only way for us to know ahead of time how to decode the text would be using GetACP() from Windows. Don't know how I feel about having platform-specific code in Lofty, though.

[Ferry-200]

Maybe we can simply set the way to decode text when reading riff info. Obviously it is not a good way to fix it though.

And this is the way how the Taglib support it. StringHandler

StringHandler

Detailed Description

An abstraction for the string to data encoding in Info tags.

RIFF INFO tag has no clear definitions about character encodings. In practice, local encoding of each system is largely used and UTF-8 is popular too.

Here is an option to read and write tags in your preferred encoding by subclassing this class, reimplementing parse() and render() and setting your reimplementation as the default with Info::Tag::setStringHandler().

[Serial-ATA]

That would also work. Gonna have to think about this one. For now I'd just recommend changing the encoding of your files to UTF-8, that's what most libraries (outside of TagLib) will exclusively support.

[aMytho]

Being able to use alternate encodings would be nice. In my project I need to build an index of all tag data (title/artist/genre/etc). I'm guessing these files are in UTF16 so I'm having the same issue.

They are able to be read in KDE Elisa. I think that project uses taglib though.

[Serial-ATA]

They are able to be read in KDE Elisa. I think that project uses taglib though.

Do your files have other tags? In the case of the file provided in this issue, it has both a RIFF INFO and an ID3v2 tag. Elisa ends up just using the data from the ID3v2 tag and logs UTF-8 errors for the RIFF INFO tag.

[aMytho]

I added metadata to several .wav files with musicbrainz picard. I think picard adds ID3v2 tags and RIFF Info tags to wavs by default. How would I check the tag types?

Running ffprobe against it shows the metadata with a warning simlar to: [json @ 0x5664cd0010c0] 1 invalid UTF-8 sequence(s) found in string 'Example�s', replaced with '�'. The missing character should be an apostrophe.

I have another file with the ellipses character. It also fails in lofty. No errors in ffprobe or elisa.

I have other files with non-english characters. They play in Elisa and I can view the metadata correctly there. When I pass the files into lofty, I get the following error: FileDecoding(Wav: "Failed to read RIFF INFO item value")

[Serial-ATA]

I think picard adds ID3v2 tags and RIFF Info tags to wavs by default.

That's probably it. Most serious music players will check all tags to fill in any missing fields. Trying to load a non UTF-8 RIFF INFO tag with Elisa will log errors, and it will fallback to the info it can get from the ID3v2 tag. Elisa just depends on KFileMetaData which uses TagLib, and as far as I can tell they don't set a StringHandler.

I will say, a hard error shouldn't be the case outside of ParsingMode::Strict. That's something I can fix (just ignore it and log a warning, like TagLib).

How would I check the tag types?

I use kid3 to see what tags a file has. It uses TagLib, and with the asset provided in the issue, it ignores any field in the RIFF INFO tag that it can't parse as UTF-8.

[aMytho]

I downloaded the kid3 program. The files that failed to read in lofy had an ID3 and a RIFF tag. Some also had extra tags, but it didn't list a type or any info.

I noticed some files display the data correctly in the ID3 tag, but show an empty entry in the RIFF tag. For example, the file with the invalid UTF8 warning when inspected with ffprobe had an apostrophe in the title. It is visible in the ID3 tag, but the RIFF tag shows the title as empty (key exists, no value). Other values were replaced instead. ID3 has a - (dash) in the artist entry while RIFF has a ? (question mark).

[Serial-ATA]

Some also had extra tags, but it didn't list a type or any info.

Kid3 puts markers to show that you can add another tag to the file, not necessarily that it's present, BTW.

It is visible in the ID3 tag, but the RIFF tag shows the title as empty (key exists, no value).

Yeah, I haven't actually seen anyone make use of TagLib's StringHandler. I imagine in most cases no errors are noticed since Picard (and likely other tools) add an ID3v2 tag for compatibility. The real issue here is that in Lofty it's a hard error, rather than a discard & warn.

[Ferry-200]

From above, I think in the future read_from will log Err instead of returning Err when encountering a tag that cannot be parsed correctly. If at least one tag is parsed properly, read_from will still return OK. Otherwise, the Err will be returned.

[aMytho]

Kid3 puts markers to show that you can add another tag to the file, not necessarily that it's present, BTW.

Interesting! I've never heard of this app, but I think it will be helpful for my project. I was using picard to inspect metadata but this one seems better for what I need.