Strange matching problem (may be M4a related) about m3ugooglemusicsync HOT 6 OPEN

Smash It Up and New Rose

There are two matches (same song - different album), the one that seems to be an accurate match is the wrong case for the title. Fix would be to .lower() all the comparisons in tag compare. Though I'm not really sure why the values would be different (did you upload this song previously with another method?). Maybe get an ID3 tag editor and have a look at the file directly (including if it contains different ID3 data versions). It could be that Google defaults to using a different version of ID3 data than what this script does...

Reward and Another Girl Another Planet

The artist doesn't match ('Various Artists' compared to 'The Teardrop Explodes'). Same questions as above.

I think comparing using tolower() makes sense makes sense... though I'm interested to know why there are two copies of those songs and why the second has a lower case name...

For the various artists one; if you can let me know about the ID3 data I might be able to force the script to use the same ID3 that Google must be looking at (or get it to compare both).

For what its worth - Even if you do re-upload the same file, I think Google is smart enough to not duplicate it (I was doing some testing earlier, and when I searched for the duplicates I'd supposedly uploaded there was only ever one copy).

from m3ugooglemusicsync.

Problem is, upload is broken in the API for me. (there is an open issue in the gmusicapi about failure to upload non mp3 files), and my NAS takes forever to transcode and upload over ADSL :-(

All the music was originally uploaded using Windows Music Manager from a shared drive on my Linux NAS, I am truing to keep it all in sync including playlists.

Will investigate the files ID3 and see if I can get any more clues...

from m3ugooglemusicsync.

Still having some problems. Had a go at hacking the source, but not a python programmer, and not that familiar with mutegen library.

What I have tried to do, is add an interactive mode, where when it can't figure out the match, prompt the possibilities, and whichever match is selected, it writes a new metadata tag that references the google music id field. When run in either interactive or regular mode, any matches between the previously selected local files's "id" field and the google music id field overrides all other matching tests.

I got some of it working, but can't get the mutagen working in "easy mode" to read an "id" tag (it seems in easy mode, it can only read a known set of tags, and I can't get "hard mode" reading unknown tags either....

from m3ugooglemusicsync.

I've pushed case-insensitive tag comparison if that helps.
When are you prompting interactive mode? Any time there are matches but none of them are "perfect"?
If you want to store data in the ID3... I guess you'd use TXXX (user data).
See https://code.google.com/p/mutagen/wiki/Tutorial#Hard_Examples:_ID3 for example on how to read/write ID3 with mutagen (my mutagen knowledge is very limited I'm afraid).

Alternatively of course you could just write all the data to a separate file in the same folder as the playlist and store any match-data in there.

If you could get an ID3 dump of the files as requested above (all the ID3 data in the files - potentially multiple versions) then I might be able to fix the underlying problem (which may mean getting a different library to pull out ID3 data of a specific version).

from m3ugooglemusicsync.

Something very strange is happening Google side. I removed my problematic albums from Google Music, reuploaded them, and still it failed on the same old tracks...

In the end, I got it working by doing lowercase comparisons and doing an "or" on the albumArtist as follows:

    return g_song['title'].lower() == tag['title'].lower() and\
           g_song['artist'].lower() == tag['artist'].lower() or\
           g_song['albumArtist'].lower() == tag['artist'].lower() and\
           g_song['album'].lower() == tag['album'].lower() and\
           g_song['track'] == tag['track']

It now syncs my playlists correctly. It does start throwing protocol errors when you try and upload over 1000 playlist items (as Google Music sadly only supports playlists upto 1000 songs).

from m3ugooglemusicsync.

Thanks for the info. I might try to see if I can have a play around with figuring out which version of ID3 tags GM prioritises.

I'll throw in a warning/check for the 1000 limit too I suppose.

from m3ugooglemusicsync.