deadbeef
deadbeef copied to clipboard
DeaDBeeF-Player
Rating metadata remapping for various file / tag formats
Introduction
Currently, Deadbeef mostly interprets Rating as a text field, and writes it "as-is". This is fine for when the rating tag simply needs to be preserved when modifying the existing tags. But this is not enough to make deadbeef add rating field in a way compatible with other applications. For example, when converting from MP3 to FLAC -- the existing rating tag would not be converted at all, and it would not be compatible.
Proposal [DRAFT, open for discussion]
Deadbeef should remap the rating to a common range when reading from tags. The preferred internal range should be [0,5], and it can be floating point to have more precision. This will allow to stay compatible with Foobar2000, title formatting in particular.
The rating value should be remapped into the destination tag format when writing tags.
The remapping for reading and writing must be implemented individually for each tag reader / writer.
The UI code should assume that the rating is always using the range of [0,5], and not attempt to do any additional remapping.
FMPS Standard
FMPS rating is part of the Free Media Player Specifications. This standard seems to be used by some linux players, but it's unclear whether it's a de-facto standard across media players in general.
What other players are doing
Foobar 2000
- No built-in functionality
- https://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Components/Playback_Statistics_v3.x_(foo_playcount)
- foo_playcount collects the data in an external database by default (
Application Data/foobar2000/index-data/C653739F-14B3-4EF2-819B-A3E2883230AE) - It can export the ratings to file tags, but without performing any remapping. The rating of 4 stars appears as RATING=4 in FLAC tag.
- FMPS_Rating support: seems to be unsupported, and non-remapped. Written to the files as-is.
Thank you for opening this issue.
In this prior issue, Songs ratings and playcount as POPM fields · Issue #1143f, you said:
I will look into adding POPM support. Can you name another music player, which supports POPM correctly, so that I could test the compatibility?
In that spirit, I will kick off the discussion with a suggestion. I think GMusicBrowser (GMB) does a particularly good job with Vorbis/FLAC ratings. It saves the ratings metadata in a way that is compatible with a number of other music players I have looked at. And the source code (Perl) is available for you to review, if you wish. Here's a link:
My comment here is related to Vorbis/FLAC ratings only.
GMB uses a scale of 0 to 100 in the GUI and it maps it to stars as follows:
Assign 0 to 5 stars via the GUI and the numeric value is:
- 0 stars: 0
- 1 star: 20
- 2 stars: 40
- 3 stars: 60
- 4 stars: 80
- 5 stars: 100
However, you can assign any value from 0 to 100 and they are mapped to stars as follows:
- 0 to 19: 0 stars
- 20 to 39: 1 star
- 40 to 59: 2 stars
- 60 to 79: 3 stars
- 80 to 99: 4 stars
- 100: 5 stars
The values of 0 to 100 are converted to decimals 0.0 to 1.0 and this is the value saved in the file's metadata. GMB uses the tag FMPS_RATING, as you will see in the source code. In my testing, that's the only tag used, although the source references FMPS_RATING_USER too.
I vote for this same approach for DeadBeef: use FMPS_RATING tag and save value 0.0 to 1.0.
Originally, this comment, More Compliant Vorbis Comment Ratings (RATING=0-100 scale) · Issue #3533 · quodlibet/quodlibet convinced me that saving 0 to 100 into the metadata field was the most popular approach, but as I have investigated further, I see more players saving FLAC ratings metadata with the 0.0 to 1.0 scale. For example Quod Libet uses that scale. However, in my limited experience, GMB is the player to look at for a good implementation.
Seems to be using the built-in media library database. Uses [0,5] range
But it is possible to record statistics in tags. And the values should be converted according to the file format tag specification (rating 0..255 for mp3 files, for example, if I remember exactly)
in foobar?
Yes, I checked the tag values after they were recorded by the plugin for collecting statistics.
@237dmitry I couldn't find any indication of rating data in the files after updating a rating using foobar / foo_playcount.
@237dmitry ahh, I found it -- it's implemented as a separate menu option "Write statistics to file tags". Thanks for pointing it out.
And timestamps in foobar2000 (Adding to library, First and Last played) in FileTime format:
# powershell
PS > (Get-Date).ToFileTime()
132776775877669815
PS > [datetime]::FromFileTime(132776775877669815).ToString('yyyy-MM-dd HH:mm:ss')
2021-10-02 22:46:27
Wouldn't it be easiest to leave everything as it is and adjust the rating plugin? If in Vorbis Comments the frame FMPS_Rating is used for rating, we could continue to use the existing rating frame that DeaDBeeF uses internally with the values 0-255 for MP3 and 0-5 for Flac/Ogg. The plugin would only need to save the mapped FMPS_Rating additionally when saving Flac/Ogg files. This could then be read by other players. The only disadvantage would be that Flac/Ogg files have then two rating frames, but I think that would be acceptable.
@kpcee This is the question I'm trying to figure out in this Issue :) Right now I don't have a clear answer yet. Before doing stuff - we need to figure out the most compatible way to do it.
The only disadvantage would be that Flac/Ogg files have then two rating frames, but I think that would be acceptable.
That would be acceptable to me. Your idea seems pretty cool. My FLAC files already have both 'rating' and 'FMPS_RATING' fields anyway.
I'm hoping for a final solution that is configurable. It would be great if I could define which rating metadata field I prefer to use for FLAC/Vorbis as well as the scale I prefer to have saved (i.e., either 0 to 100 or 0.0 to 1.0).
@kpcee
Wouldn't it be easiest to leave everything as it is and adjust the rating plugin?
Consider what happens if the rating plugin performs the mapping to some range (like 0 to 100) because it knows that the file is FLAC. Then the user converts the file to another format. Converter is not aware that the other format needs the rating in another range, so it stays 0 to 100, and becomes invalid (wouldn't be handled incorrectly even by deadbeef itself). Also, if deadbeef is not aware of the rating range internally -- it would not be possible for the user to display the rating via title formatting, without having to deal with file formats.
With all that, I guess it's not easy to leave everything in the plugin if we decide to perform remapping. Also at this point I'm not sure whether adding such remapping is a good idea in general.
The idea is that DeaDBeeF still writes its own rating frame and thus knows completely independent of the format what kind of rating it is. Internally DeaDBeeF works with 0-5, only with MP3 this value is already mapped to 0-255 when saving and converted internally to 0-5 again when loading.
The rating plugin would write only another frame. But this FMPS_Rating would be completely ignored by DeaDBeeF and is only intended for other players that support this frame. Internally DeaDBeeF would use its own rating frame.
The advantage is that we don't need to make any changes to DeaDBeeF, only to the plugin. The disadvantage is that we have two rating frames in the music files with Vorbis Comments. If you want to avoid two rating frames, you would have to put all this into DeaDBeeF and since there is no uniform standard, it would still not be 100% perfect.
Consider what happens if the rating plugin performs the mapping to some range (like 0 to 100) because it knows that the file is FLAC. Then the user converts the file to another format. Converter is not aware that the other format needs the rating in another range, so it stays 0 to 100, and becomes invalid (wouldn't be handled incorrectly even by deadbeef itself).
Yes, I agree, but it can't be avoided and affects all other players as well. Since there is no standard for Vorbis Comments and every player uses a different range of values to rate the music (0-100 vs 0.0-1.0). A conversion from FLAC → MP3 would include an invalid FMPS_Rating and also the own rating frame of DeaDBeeF would become invalid. A conversion to e.g. FLAC → Vorbis, Theora, Speex and Opus on the other hand would work, since all formats use Vorbis Comments.
But to be honest I don't see that as a problem, because it's enough to switch to another player that all the ratings can become invalid because there is no unified standard. If the user converts the files to another format, he will later have invalid ratings on all other players as well and will have to adjust them manually.
The idea is that DeaDBeeF still writes its own rating frame and thus knows completely independent of the format what kind of rating it is.
The point of this github issue is that currently deadbeef doesn't care or "know" about rating field (except POPM in MP3), and writes it "as-is" without any remapping.
If you want to avoid two rating frames
No, I don't mind this at all.
A conversion from FLAC → MP3 would include an invalid FMPS_Rating and also the own rating frame of DeaDBeeF would become invalid.
No, this should not be a problem since FMPS_Rating is exactly the same in MP3 and FLAC, according to the FMPS spec.
The point of this github issue is that currently deadbeef doesn't care or "know" about rating field (except POPM in MP3), and writes it "as-is" without any remapping.
Yes and exactly this circumstance makes it easy to create the FMPS_Rating frame, we don't have to deal with the different scales and we can ignore it completely.
No, this should not be a problem since FMPS_Rating is exactly the same in MP3 and FLAC, according to the FMPS spec.
Yes the FMPS_Rating frame keeps its validity, however the DeaDBeeF rating, if it would be converted into a POPM during the conversion, would lose its validity. Since the value of 0-5 would not be mapped to 0-255.
So all in all it's not easy, if the rating plugin should be adapted, I could take care of that, otherwise, I have no further opinion on the subject.
however the DeaDBeeF rating, if it would be converted into a POPM during the conversion, would lose its validity.
Yes, agreed -- this conversion should not occur at all. FMPS rating and the regular rating should not be auto-translated / synced by the deadbeef tag writer - this in itself would prevent the plugin to set them independently.