Florian -
How are you intending the x/xx format to work in 2.35b? In iTunes I see the track and total number of tracks in two fields, MP3Tag obviously now shows them in one.
Also - when I edit the track & total track in iTunes, I'm not seeing the changes in MP3Tag.
Disc and total discs also shows in two fields in iTunes as well yet they are still seperate in MP3Tag.
Logan,
Yes, this is exactly my intention. So the format of the tracknumbers is also compatible with the Auto-numbering wizard. It's still saved in these two seperate fields, but this is done transparent to the user.
Yes, this is because Mp3tag prefers another tag format which is written to the files over Apple's hack.
Yes, I think that's okay.
Best regards,
~ Florian
Yes, this is exactly my intention. So the format of the tracknumbers is also compatible with the Auto-numbering wizard. It's still saved in these two seperate fields, but this is done transparent to the user.
It would be nice to have visility to the actual fields, with the new functionality I need to modify all my Actions that touch the Track Number & Total Tracks fields to first check the tag type and then perform on of two actions. Example: updating the total tracks fields.
Yes, this is because Mp3tag prefers another tag format which is written to the files over Apple's hack.
Bummer - It's unfortunate that they implemented it that way, shouldn't have to work around their hack.
Yes, I think that's okay.
That surprises me somewhat, in iTunes they are displayed the same way and they both represent "parent\child" relationships. Is this point open for discussion?
It would be nice to have visility to the actual fields, with the new functionality I need to modify all my Actions that touch the Track Number & Total Tracks fields to first check the tag type and then perform on of two actions. Example: updating the total tracks fields.
Good point. Maybe it would be better if Mp3tag would support entering #/## format, but would display track and total tracks in seperate fields.
Bummer - It's unfortunate that they implemented it that way, shouldn't have to work around their hack.
I'll disable writing of this other format on single chapter MP4s to the next release.
That surprises me somewhat, in iTunes they are displayed the same way and they both represent "parent\child" relationships. Is this point open for discussion?
Yeah, feel free to give suggestions on how to solve this.
Best regards,
~ Florian
Thanks for the replies Florian.
On the Tracks & Total Tracks\Discs & Total Discs topic, my point of view is that they should behave in the same way since (to me) they are the same construct. I don't think we should have to different formats for the same concept.
I know you been very busy with updates, I was just curious to see if this was on your internal list.
Track and Discnumber should now both be in #/# Format (but #/# for discnumber at mp4 still needs to be fixed)
I'm still seeing very inconsistant actions between MP3 & M4A files.
This is example is via the Tags dialog.
MP3 -
Add: TRACK = 1 & TOTALTRACKS = 10
Result: Track = 1 & TotalTracks = 10
M4A -
Add: TRACK = 1 & TOTALTRACKS = 10
Result: Track = 1/10 & TotalTracks =
I finally came to a conclusion: I'll make display and write both TRACK and DISCNUMBER fields in #/## for MP3 and MP4.
If you add sth like TOTALTRACKS or TOTALDISCS it depends on the tag format if the field is added or not.
This was implemented with the latest Development Build.
Here is what I'm seeing, would like to confirm that this is the expected action:
This is example is via the Tags dialog.
MP3 -
Add: TRACK = 1 & TOTALTRACKS = 10
Result: Track = 1 & TotalTracks = 10
M4A -
Add: TRACK = 1 & TOTALTRACKS = 10
Result: Track = 1/10 & TotalTracks =
Update: TOTALTRACKS = 11
Result: Track = 1/10 & TotalTracks = .
In effect, there is no change when the update is saved.
I see the problem but I have really no idea how to circumvent that.
You won't have any problems if you wouldn't use the TOTALTRACKS field but the #/## format for TRACK. Same behaviour for MP3 and MP4
The problem with adding/updating the TOTALTRACKS field is, that if the TRACK field is in #/## format, I have to split it in
I really have no idea to make both alternatives work with Mp3tag.
Not sure if this helps, but here is how iTunes has it implemented (not that it's better, just a different perspective). This behaves the same for MP3 & M4A alike.
Browser Window
Get Info dialog
COM interface (only reason I like iTunes)
Now, with that said, here's what I'm seeing:
Test A
MP3:
iTunes: Update Track Number (two fields) to 1 of 10 & Disc Number (two fields) to 1 of 1
MP3Tag: %track% = 1/10 & %discnumber% = 1/1, both %totaltracks% & %totaldiscs% are blank
M4A:
same result as MP3
Test B
MP3:
MP3Tag: Update %track% = 1, %totaltracks% = 10 & %discnumber% = 1, %totaldiscs% = 10
iTunes: Track Number = 1 of & Disc Number = 1 of
M4A:
MP3Tag: same as MP3
iTunes: Track Number = 1 of 10 & Disc Number = 1 of 1
This is because ID3v2 doesn't have an extra TOTALTRACKS or TOTALDISCS field specified. If you create these fields, Mp3tag stores them as user defined TXXX frames. Both values are stored in TRACK and DISCNUMBER (separated by a slash).
This is because the current version hides the TOTALTRACKS and TOTALDISCS fields from the user to display the same as for MP3.
This is because you've created extra TXXX frames for TOTALTRACKS and TOTALDISCS. If you want these values automatically mapped to x/xx format in TRACK or DISCNUMBER, the fields won't be available to users who use these fields in other programs (like foobar2000).
I still have no idea how to solve this. These tests are not very new to me.
Looks like there was a change made with the latest developement build.
Did you revert back to old code or have you implemented a new solution?
Yes, I've changed MP4 track/discnumber field to accept input in #/## format, but I'm displaying them as seperate track/totaltracks and discnumber/totaldiscs fields (because they're stored as seperate fields in the tag).
MP3 track/discnumber handling has not been changed.