I've noticed a bug, which is present in the RC2, but was allready present in RC1. I can't tell about any version below v3, since I've never used them (new to MM, started with v3 RC1).
MM gives all my AAC (.m4a) files the discnumber 65536 and BPM 65536. Just the AAC files, MP3 work fine. I'm not using the discnumber and BPM tag on these files.
I've noticed after syncing it to my Sansa e200 with the d_WMDM.dll plugin. The files on the PC are affected as well as the synced files on the Sansa. My sansa reads the disc# and BMP tag, Mp3Tag also does, but MM doesn't show them when I click on properties.
RC2: AAC disc# and BPM tags incorrect [NOTREP]
Moderator: Gurus
Disc# and BPM fields incorrect
Kugel,
A can't reproduce this.
Can you clarify? Are you saying that MM is actually changing the tags of the tracks on your PC? Or that when MM syncs to the device, the metadata of the track as it exists on the device is incorrect?
Also, is auto-conversion enabled?
Are you doing an auto-sync or manual sync?
How exactly is this triggered (can you give me a set of steps that reproduce this)?
Thx.
-Rusty
A can't reproduce this.
Can you clarify? Are you saying that MM is actually changing the tags of the tracks on your PC? Or that when MM syncs to the device, the metadata of the track as it exists on the device is incorrect?
Also, is auto-conversion enabled?
Are you doing an auto-sync or manual sync?
How exactly is this triggered (can you give me a set of steps that reproduce this)?
Thx.
-Rusty
-
kugel.
I can reproduce it partly with RC4.
RC4 just changed 1 thing: The disc# isn't going to 65536, but to 0 (seems to have something to do with this on change in RC4 to the M4A disc# tag).
Also, it does NOT happen upon sync'ing ANYMORE. It did in the previous versions (at least from what I can tell from 1 sync).
But, it happens when I rate a M4A. The file get's a 65536 written into BMP tag and 0 into disc# tag.
But I noticed some other thing: Like the both tags, it adds something into some replaygain tags. I know what replaygain is, and I never used it, especially not with MM. Even worse, I can't get them deleted, aka they will show up in MM no matter how often I delete this replaygain tags with MP3 tag.
To answer your other questions, I have auto-sync enabled for my Sansa e200 (using d_WMDM.dll), and I have auto-conversion NOT enabled (I don't own a gold edition).
RC4 just changed 1 thing: The disc# isn't going to 65536, but to 0 (seems to have something to do with this on change in RC4 to the M4A disc# tag).
Also, it does NOT happen upon sync'ing ANYMORE. It did in the previous versions (at least from what I can tell from 1 sync).
But, it happens when I rate a M4A. The file get's a 65536 written into BMP tag and 0 into disc# tag.
But I noticed some other thing: Like the both tags, it adds something into some replaygain tags. I know what replaygain is, and I never used it, especially not with MM. Even worse, I can't get them deleted, aka they will show up in MM no matter how often I delete this replaygain tags with MP3 tag.
To answer your other questions, I have auto-sync enabled for my Sansa e200 (using d_WMDM.dll), and I have auto-conversion NOT enabled (I don't own a gold edition).
Rusty,
I just noticed this post. I have had similar issues with m4a files--it changes the track number on the PC... I am not sure if this happens when syncing or when trying to update the tags. i have not had time to ry this, since I have not been using MM3 to sync. Now that the iPod bugs are getting resolved, I will try and reproduce.
Thanks,
John
I just noticed this post. I have had similar issues with m4a files--it changes the track number on the PC... I am not sure if this happens when syncing or when trying to update the tags. i have not had time to ry this, since I have not been using MM3 to sync. Now that the iPod bugs are getting resolved, I will try and reproduce.
Thanks,
John
65535 in some fields
I suspect that the following has happened:
1) the tracks on the iPod were synched with an earlier prerelease build and have a bug in which some fields appear as 65535 instead of empty
2) when you rate the track on the iPod, it causes it to synch back to MM
3) when it synchs back to MM, the track number gets modified to the iPods value
Try deleting tracks from the iPod and resynching. Then see if you can reproudce the problem.
Thx.
-Rusty
edit: Kugel, I am assuming that when you say that you rate the track, you mean that you rate the track on the iPod and then upon connecting the iPod to MM, the rating and incorrect track# info get 'synched' back to MM. If I misunderstood, please clarify.
1) the tracks on the iPod were synched with an earlier prerelease build and have a bug in which some fields appear as 65535 instead of empty
2) when you rate the track on the iPod, it causes it to synch back to MM
3) when it synchs back to MM, the track number gets modified to the iPods value
Try deleting tracks from the iPod and resynching. Then see if you can reproudce the problem.
Thx.
-Rusty
edit: Kugel, I am assuming that when you say that you rate the track, you mean that you rate the track on the iPod and then upon connecting the iPod to MM, the rating and incorrect track# info get 'synched' back to MM. If I misunderstood, please clarify.
Strange, as I am having no problems replicating the problem described in this topic. I just made a fresh CD rip to AAC (in a MP4 container as usual), and if I even just try to rate one of these tracks from MediaMonkey it messes up and adds a TEMPO tag with a value of "65535 BPM" desipite never having any such tag in the first place.
Not only that, but it also adds the following tags, which have never been there and never should be there according to how I organize my music and artwork:
COVERARTFILELINK2
COVERARTTYPE2
(sometimes the number at the end is 1 instead of 2)
It no longer adds "65535" as the disc number, but instead adds the tag with a value of "0" despite the fact that I *never* use that tag for single-disc albums. In my case, there are no syncing involved and there never has been for these albums I tested with.
It would be nice if MediaMonkey would stop adding stuff to my tags that I never asked for...
EDIT: MediaMonkey also delete at least the following tags if they exist, as soon as I just rate a MP4:
TOTALTRACKS
TOTALDISCS
It possibly deletes more, but those are the ones I've noticed.
Not only that, but it also adds the following tags, which have never been there and never should be there according to how I organize my music and artwork:
COVERARTFILELINK2
COVERARTTYPE2
(sometimes the number at the end is 1 instead of 2)
It no longer adds "65535" as the disc number, but instead adds the tag with a value of "0" despite the fact that I *never* use that tag for single-disc albums. In my case, there are no syncing involved and there never has been for these albums I tested with.
It would be nice if MediaMonkey would stop adding stuff to my tags that I never asked for...
EDIT: MediaMonkey also delete at least the following tags if they exist, as soon as I just rate a MP4:
TOTALTRACKS
TOTALDISCS
It possibly deletes more, but those are the ones I've noticed.
Dirhael,
you are right in your comments, there are several things that can be improved in order to tag M4A files better - it will be in the next release.
Just re. COVERARTxxx fields - they are tagged only when needed, e.g. when you enter a description to an image, without this field stored in tag, it would be lost.
Jiri
you are right in your comments, there are several things that can be improved in order to tag M4A files better - it will be in the next release.
Just re. COVERARTxxx fields - they are tagged only when needed, e.g. when you enter a description to an image, without this field stored in tag, it would be lost.
Jiri
Good to hear it's going to be improvedjiri wrote:Dirhael,
you are right in your comments, there are several things that can be improved in order to tag M4A files better - it will be in the next release.
Just re. COVERARTxxx fields - they are tagged only when needed, e.g. when you enter a description to an image, without this field stored in tag, it would be lost.
Jiri
What you're saying about the COVERARTxxx fields confuses me though, because as I said I never did anything other than just rate my freshly ripped MP4's (which was ripped outside of MM), so there never have been any description or even cover added to these files. The only thing related to a cover is a folder.jpg stored in the same folder as the files, so there is absolutely no reason for MM to add those tags to my files, and I'd appreciate it if the program would stop this annoying behaviour. It does not add them [these COVERARTxxx tags] to any files ripped as MP3, so I refuse to believe that they are needed for MM to handle other filetypes organized in the exact same manner.