[1464] / in track no not displaying? [#4920]

[BKKKPewsey]

Sorry it's me again
I just did a check for unsynchronised tags in my library and about 100 tracks from 1 artist came back showing that the replaygain tags were not synced.
So I did the usual cntrl S and synced the tags - rescanned for unsynchronised files and they all came back again.
So I cleared the tags using tools\ clean tags and synced again - rescanned and they came back again
So I powered up mp3tag and looked at the tags
All the replaygain tags has the correct info even though MM was saying they were not synchronised however I noticed that the track no's were in the form of x/y
eg 1/9 (track 1 of 9).
This was not being displayed in MM which was showing the track no as 1
So I delved a little deeper and changed track 1 to 1/9 in MM - checked in mp3tag and the track no was now showing 1/9/9
So I then selected the whole album and deleted all the track numbers in MM which resulted in mp3tag now showing the track tags as /9
So it would appear that:

1. That MM is ignoring "/xx" not displaying tracks no's with /XX part.
2. Is getting confused in that it is then reporting that it is the replaygain tags which are not synchronised.

Here is the MP3Tag view



And MM4



I also checked with MM3 and that has the same problem so it appears not to be a new "feature"

[Mizery_Made]

The disc/track number thing is already a known issue: 5876 & 5878

[BKKKPewsey]

Whoa! reported in 2009 no wonder I missed it.
So it's about time this issue was fixed especially as its messing up synchronising tag operation
and the clean ID tags should have deleted those entries and didn't.
Of course perhaps MM should come bundled with MP3Tag

From the ID3.org website

TRCK
The 'Track number/Position in set' frame is a numeric string containing the order number of the audio-file on its original recording. This may be extended with a "/" character and a numeric string containing the total numer of tracks/elements on the original recording. E.g. "4/9".

So its not exactly non-standard

[MeeMeeMee]

Strange, but for FLAC files (vorbis comment) this <track>/<total> values in the track# tag works fine.

[theta_wave]

Whoa! reported in 2009 no wonder I missed it.
So it's about time this issue was fixed especially as its messing up synchronising tag operation
and the clean ID tags should have deleted those entries and didn't.
Of course perhaps MM should come bundled with MP3Tag

You can create a new hotkey combo to launch mp3tag from within mediamonkey using the externaltools script. Select the music file, press the hotkey combo, and mp3tag launches and works in the directory of the selected file.

[BKKKPewsey]

You can create a new hotkey combo to launch mp3tag from within mediamonkey using the externaltools script. Select the music file, press the hotkey combo, and mp3tag launches and works in the directory of the selected file.

Thanks for that - had to jump through a few hoops to get it working (portable Mode) and then to find the right parameters but all working now.
Mind you it would be a lot better if I didn't need an external tag editing program - rather defeats the point of MM

[BKKKPewsey]

Just an update to the devs ref: [1466] - The clean ID tags is now actually removing all track no. info eg. blanking them
so clean and resync tag will now get the tags matching the library.
Why it was not working correctly in 1464 (leaving the /xx part in the track tag) I have no idea

It would still be nice to see them though rather then having to rely on a 3rd party app.

[BKKKPewsey]

Further info
This bug causes major disruption to the volume analysis and put MM into an endless cycle which requires a shutdown via task manager.
If you scan in tracks in which have tracks no's in the format xx/yy - MM will only show the xx part (therefore you are not aware of the problem
- and discussed in previous posts)
If you then use automatic volume analysis as far as MM is concerned it will fail for all those tracks eg no data shown just exclamation marks.
(If you check with MP3tag however the replaygain tags are written ok).
This means MM will then try to analyse those tracks again and so on.
I had debugView running at the time and MM was opening a thread and then closing that thread constantly - the only way to stop it was to use taskmanager.
Can the dev's check on this please as it seems to be a major issue.
If you require any further info please ask - unfortunately I do not have the log saved because terminating MM wiped the log

[joltman]

I sure would like to have this functionality fixed. I'm seeing the same behavior between FLAC and MP3 Disc# and Track# in the newest 4.1.1.1703.