Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: ReplayGain—bugs related to differences in file vs. cached values, etc. (Read 4291 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

ReplayGain—bugs related to differences in file vs. cached values, etc.

Hello,

I have just started using foobar2000 v1.2 to organize my music collection, and I find it a wonderful tool - my gratitude goes out to the developers and other users who help polish it further.

The tags in my collection are currently lacking in quality, and use mp3tag to update them and foobar2000 v1.2 to add ReplayGain info. A simple example of what isn't quite working right:

1. I start with file set containing mistagged compilation (ie, AlbumArtist info not set). In fb2000, this shows up as 10 different albums.
2. This is not right so I alt-tab to the mp3tag window, and add "Various Artists" to the AlbumArtist.
3. Then I alt-tab back to fb2000, select all the songs belonging to this compilation, and select "ReplayGain scan using album tags".
4. The result of this scan shows multiple Album ReplayGain values, as if the tracks belong to different Albums. At the same time, fb2000 notices the updated AlbumArtist tag, and re-organizes all the tracks under one single album. Great.
5. I hit Cancel, since the ReplayGain info reflects old album info.
6. I start a second ReplayGain sacan using album tags, but this time fb2000 correctly reports all tracks having the same album replay gain value.
7. I Hit Update tags. Life is good.

What I would expect happen is that at step 4, the fresh tag info from the files, which at this point is different from foobar's database, be used to group all the tracks into one album, and thus eliminate the need for steps 5 and 6.

This bug is not serious, as in the end I'm able to get the desired result.

Thank you for your consideration.

Edit: I initially reported this for 1.1.11 but I noticed the ReplayGain feature was modified in the 1.1.16 release, so I retested the current stable version (1.2 at this time). The bug is still there in 1.2

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #1
Any particular reason you cannot add the album artist tag with foobar? It's the simplest solution.

Otherwise, between steps 2 and 3 you could select the album in foobar, then right-click it and in the context menu select Tagging > Reload info from file(s). Pretty sure that will make foobar see that there are now album artist tags in those files, so no more steps 4 through 7.

As you seem to know, foobar uses its database. It doesn't know the files' metadata have changed until it rescans your media library or you alter the metadata in foobar (such as replaygain scanning).

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #2
Any particular reason you cannot add the album artist tag with foobar? It's the simplest solution.


This is a very good suggestion; I didn't use it initially because I was not familiar with how to do it. After reading your suggestion, I found that selecting all the tracks and hitting Properties in the Context Menu allows me to edit the tags in foobar. Brilliant, thanks!

I find mp3tag more suited to tag maintenance as it allows you to clean up tags on a file set, before importing new files into the library, while foobar is a library-centered tool. If you'd import new files into foobar without cleanup first, the new files would be hard to find, unless the tags were correct prior to importing. mp3tag is very valuable in library maintenance.

Otherwise, between steps 2 and 3 you could select the album in foobar, then right-click it and in the context menu select Tagging > Reload info from file(s). Pretty sure that will make foobar see that there are now album artist tags in those files, so no more steps 4 through 7.

As you seem to know, foobar uses its database. It doesn't know the files' metadata have changed until it rescans your media library or you alter the metadata in foobar (such as replaygain scanning).


My install (v1.2) does not seem to have the Tagging > Reload info from file(s) functionality - perhaps it's a plugin.

Well, thank you for your suggestion above, it does simplify task a lot.

Indeed foobar uses its database, however the scan operation also updates the database. Using the stale info instead of the fresh info during an updating operation does not make sense, however.

Anyway, I'm a happier camper now. Thank you!

Edit: Added reason why mp3tag is essential and still needed in the workflow.

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #3
I have nothing against Mp3tag as I use it myself. I just didn't understand why you used it to do something as simple as adding an album artist tag to your files when using foobar would suffice.

My install (v1.2) does not seem to have the Tagging > Reload info from file(s) functionality - perhaps it's a plugin.

Go to File > Preferences > Context Menu. Under Tagging, you'll need to tick the box for Reload info from file(s) for it to show in the context menu.

Indeed foobar uses its database, however the scan operation also updates the database. Using the stale info instead of the fresh info during an updating operation does not make sense, however.

*sighs*

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #4
I have nothing against Mp3tag as I use it myself. I just didn't understand why you used it to do something as simple as adding an album artist tag to your files when using foobar would suffice.


I found a couple more bugs related to the interaction between cached (db) data and file data:

bug 1:
1. I have an album of 12 tracks whose artist tag is mis-capitalized ("Ace Of Base" instead of "Ace of Base").
2. To fix it, I select the album in fb2k and press alt-Enter, then update the artist name to "Ace of Base"
3. Great - the Metadata window now shows the updated, correct capitalization, however the Album List pane still shows the old capitalization.
4. I expected the library view to update automatically, but anyhow, I hit "Context"->Tagging->Reload info from files, trying to manually update the db.
5. The album list still shows the old capitalization ("Ace Of Base")
6. Double checking with mp3tag, the tags in the files were updated correctly ("Ace of Base")

It appears the database (or at least the library view) doesn't update if the metadata change is only capitalization.

bug 2.
1. I need to update ReplayGain data for an album of 12 tracks. Sadly, the artist on one track is "Ace Of Base", while the other 11 is "Ace of Base", all other album info being consistent.
2. In the library view, all these 12 tracks are grouped as one album. Great.
3. I hit ReplayGain->"Scan Selection as album (by tags)", and unexpectedly, the odd track is detected as having a different Album gain than the other 11.

In this case it seems the library scanner uses case insensitive album grouping, while the RealplayGain scanner uses case sensitive matching. The case could be made for either one to be considered correct, but they should be consistent. I would suggest case sensitive matching is more correct, as this is more likely to match other library scanners that use the same tags to create their own databases, such as Squeezebox.

Should I submit these two bugs separately from this thread?

I've been using mp3tag for a long time, and being more familiar with it, it's easier for me to get expected behaviour. I'm just starting to use fb2k, so I'm not as versed with getting it to do what I need done. Maybe in time one of them will become redundant.

I'm providing this feedback because I think it's useful to the developers to get usability feedback from a novice, and novices who are willing to document their experience are hard to find. In a few weeks I won't have a first-time-user's perspective any more.

To be sure, these are very minor issues. 

 

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #5
bug 1:
1. I have an album of 12 tracks whose artist tag is mis-capitalized ("Ace Of Base" instead of "Ace of Base").
2. To fix it, I select the album in fb2k and press alt-Enter, then update the artist name to "Ace of Base"
3. Great - the Metadata window now shows the updated, correct capitalization, however the Album List pane still shows the old capitalization.
4. I expected the library view to update automatically, but anyhow, I hit "Context"->Tagging->Reload info from files, trying to manually update the db.
5. The album list still shows the old capitalization ("Ace Of Base")
6. Double checking with mp3tag, the tags in the files were updated correctly ("Ace of Base")

It appears the database (or at least the library view) doesn't update if the metadata change is only capitalization.

As per my personal user experience, any changes I make to the metadata using foobar are immediately reflected in the playlist, and any changes I make using Mp3tag are immediately reflected in the playlist once I reload the info from the files.

Now, as to the album list, it indeed does not immediately reflect metadata changes. It appears to access the database only in order to populate itself, then stops. If you change the view in album list, this causes it to access the database again and metadata changes are reflected.

bug 2.
1. I need to update ReplayGain data for an album of 12 tracks. Sadly, the artist on one track is "Ace Of Base", while the other 11 is "Ace of Base", all other album info being consistent.
2. In the library view, all these 12 tracks are grouped as one album. Great.
3. I hit ReplayGain->"Scan Selection as album (by tags)", and unexpectedly, the odd track is detected as having a different Album gain than the other 11.

In this case it seems the library scanner uses case insensitive album grouping, while the RealplayGain scanner uses case sensitive matching. The case could be made for either one to be considered correct, but they should be consistent. I would suggest case sensitive matching is more correct, as this is more likely to match other library scanners that use the same tags to create their own databases, such as Squeezebox.

OK, that's a little weird that replaygain scanning is case-sensitive (esp. based on an artist tag when all other tags match), but you do have the options to scan as a single album or to scan as an album by folders. On the other hand I can see where it could cause problems in certain scenarios where neither of those two options can be used and scanning as an album by tags must be used. I never use that option which is probably why I've never noticed the case-sensitive scanning before.

ReplayGain—bugs related to differences in file vs. cached values, etc.

Reply #6
Should I submit these two bugs separately from this thread?
If you’re happy to keep them here, I’ve renamed it to reflect your common grouping of them under “the interaction between cached (db) data and file data”. You could request a split if you prefer it, but I think it’s probably OK like this (for now!).