Getting metadata from an mp3 stream with ReadOnlySource

[GeoffClements]

This is an issue for me but is really just a question as it may not be a bug.

I'm streaming an audio file and using ReadOnlySource. At the beginning of the stream I want to announce the artist etc, so I'm interesting in the metadata from ProbeResult.

When I stream flacs or ogg/vorbis this works fine but on mp3 files I don't get any metadata, neither from ProbeResult.format.metadata() nor from ProbeResult.metadata.get().

The interesting thing is that when I use the example symphonia-play on the exact same file, now not streamed but read from the disk, the metadata is extracted and displayed correctly. The only difference that I can see is that we have a MediaSourceStream rather than a ReadOnlySource, at least, that's my guess.

Am I asking the impossible of Symphonia here?

[pdeljanov]

I'll need more information to give you a definitive answer since there are some valid reasons why you may be seeing this behaviour, but it's hard to say for sure. Could you run symphonia-play with the environment variable RUST_LOG=trace and collect the logs?

MP3s typically store metadata in ID3v1 and ID3v2 tags. The former are located at the end of the file and thus can't be read if the source is unseekable, while the latter is at the front of the file. You sometimes also see APE tags which can be in both locations.

[GeoffClements]

This appeared in the log, in fact it's the only entry but I didn't play the whole file through. Looks like it might be relevant.
INFO symphonia_metadata::id3v2 > unsupported frame UFID

I suspect storing the id3v1 tags at the end of the file means that I am asking for the impossible with a read-only source. Thanks for confirming this.

I do have id3v2 tags as well as id3v1, but it looks like there is a problem with them from the log.

[GeoffClements]

I just examined the mp3 files with a hex editor and I can see the id3v2 data at the beginning. I can't be completely sure that the tags are well-formed by eye but my tag reader has no problem with them, so I'm assuming there is an issue with Symphonia.

[pdeljanov]

This appeared in the log, in fact it's the only entry but I didn't play the whole file through. Looks like it might be relevant. INFO symphonia_metadata::id3v2 > unsupported frame UFID

This shouldn't be much of an issue. It's only skipping one rarely used part of the tag.

I just examined the mp3 files with a hex editor and I can see the id3v2 data at the beginning. I can't be completely sure that the tags are well-formed by eye but my tag reader has no problem with them, so I'm assuming there is an issue with Symphonia.

This is more worrisome. Are you using a build from master or dev-0.6? The latter may fix the issue. If not, is it possible for you to share a problematic file?

[GeoffClements]

I'm using Symphonia-0.5.4. I can give dev-0.6 a try, not sure how much I need to change my code for the dev release as I haven't looked at it yet, it may take a while depending on the changes needed. In any case, I'll report back.

I'm happy to share any file but it's probably worth trying the dev branch first.

[GeoffClements]

I have now checked with the dev-06 branch. It has the same problem. Let me know if you want an example file and I'll send one.

[GeoffClements]

I've been digging into this and have discovered that the Lyrion music server is not sending id3v2 tags from mp3 files but it sends the tags from ogg and flac files, so it's being very weird. I'm raising this with the Lyrion community and will close this issue. Sorry for the noise.