Hi,
if I watch the properties of a WMA file the track number is everytime 1 higher then real. Winamp show the correct and other ID-Tagger even too.
I hope you find this bug and can eleminate this one.
With best regards
Michi
I noticed that when converting from wma to mp3 the track number of the mp3 was one higher than it should be in the resulting id3v1 and id3v2 tags of the mp3s and reported it to this forum previously. Hopefully the next release will correct this "feature" as well as they are most likely related.
I noticed that when converting from wma to mp3 the track number of the mp3 was one higher than it should be in the resulting id3v1 and id3v2 tags of the mp3s and reported it to this forum previously. Hopefully the next release will correct this "feature" as well as they are most likely related.
Yes, my library has now this 'error' in all converted files :-( . I notice this too late.
With best regards
Michael
I noticed that when converting from wma to mp3 the track number of the mp3 was one higher than it should be in the resulting id3v1 and id3v2 tags of the mp3s and reported it to this forum previously. Hopefully the next release will correct this "feature" as well as they are most likely related.
Yes, my library has now this 'error' in all converted files :-( . I notice this too late.
With best regards
Michael
Can't you just use masstagger to correct the problem?
I'm thinking something along the lines of:
Format Value from other field->
Destination Field: Title
Code: $sub(%tracknumber%,1)
I mean if it's adding 1 to all the tracknumber, why not just subtract 1 from all of them?
Can't you just use masstagger to correct the problem?
I'm thinking something along the lines of:
Format Value from other field->
Destination Field: Title
Code: $sub(%tracknumber%,1)
I mean if it's adding 1 to all the tracknumber, why not just subtract 1 from all of them?
First of all ... many thanks :-) This helps me very much.
But I hope that this extra step ist unnecessary in the next version of this great software :-)
Have a nice weekend
Michael
I just wanted to add that this problem still exists in the latest beta version. A fix would be highly appreciated...
First of all thanks for the small Masstag Script.
Works well as a workaround.
But I want to add that this "+1 Tagnumber" feature at least still is available in 0.9.4.5.
But I want to add that this "+1 Tagnumber" feature at least still is available in 0.9.4.5.
It's not in 0.9.5.
On a sidenote: The WMA tagging format is really funny when it comes to tracknumbers. The specification actually contains two attributes for storing tracknumbers. The first, WM/Track (http://msdn2.microsoft.com/en-us/library/aa392014.aspx), only exists for backward compatibility and is -- now the fun part -- zero-based! The second, WM/TrackNumber (http://msdn2.microsoft.com/en-us/library/aa392015.aspx), is surely the way to go as it is the current recommended tracknumber attribute for WMA tags without any insane constraints.
Maybe I did something wrong, but I just tried 0.9.5 beta8 and it still contains the +1 "feature".
Maybe I did something wrong, but I just tried 0.9.5 beta8 and it still contains the +1 "feature".
I can't reproduce it with freshly tagged WMA files in 0.9.5 beta 8. Can you provide step-by-step instructions on how to reproduce it?
I just drag a wma onto my playlist and it adds with actual tracknumber+1 to the playlist.
For example dragging 01 - One Vision (Extended Version).wma
(wtih tracknumber reported to be 1 in windows file details)
onto my clean default playlist
leads to a Display of Track No 02 in foobar 0.9.5 beta8.
Right click -> Properties in foobar also displays
Track Number | 2
I just uninstalled foobar (and all it's options) and reinstalled it to be sure I did not change any settings in foobar 0.9.5.beta8 just to be sure I don't report anything I can't reproduce
Can you send me (http://www.mp3tag.de/en/contact.html) this file for analyzing the issue?
See this topic:
http://www.hydrogenaudio.org/forums/index....c=61867&hl= (http://www.hydrogenaudio.org/forums/index.php?showtopic=61867&hl=)