2012-05-28, 06:35
Hi,
Noticed MusicBrainz support is sort of implemented with the MB tags cached in CSong. I was taking a look into writing an MB scraper and I noticed that the scrapers only get the Artist/Album as strings. I took a look at the code behind the MusicScanner & MusicScraper and wondered if you would be open to discussion & patches to the music scraper?
I looked at a couple of approaches to propogate MBIDs to the scrapers in the code, but my thought finally was to do the following - open to feedback:
1) I would propose to add the fields MusicBrainzArtistID -> 'artist'/CArtist, MusicBrainzAlbumID & MusicBrainzAlbumArtistID -> 'album'/CAlbum in MusicDatabase->AddSong. While I was writing this I realised this has a secondary advantage - later we can disambiguate similar named Artists/Albums etc using the strArtist & MBArtistID as the key on Artist. But in the first instance the proposal is just to propogate these fields to the Artist/Album to keep it simple. There would be issues around similar named artists but I think those same issues exist today so we're not breaking anything existing.
2) For MusicInfoScanner and MusicDatabase:
My proposal is to pass a CAlbum, CArtist, etc to DownloadAlbumInfo/DownloadArtistInfo and downstream functions instead of fixed strings strAlbum and strArtist. This way any members of the CAlbum & CArtist structs can be passed to scrapers. Later if we extend those structs it is easier to get that data to the scrapers (no refactoring the function params each time). For those source functions calling e.g. DownloadArtistInfo with only a string we'd first create a CArtist, and populate it with all of the data we have in hand. The scrapers could get more of the data available to us in order to make less amiguous decisions. With MBIDs in CArtist & CAlbum as above, we can now easily pass the scanned MBIDs to the scraper.
I have working patches to do 1) and I'm just working on part 2) of the change as a proof of concept. I notice also the MBID tags on my m4as aren't being scanned in right now, I will check that out too.
Finally this would require additional scrapers that key off MBID not 'Artist Name' etc.
I think all of this would be great for fanart.tv which already seems to key of MBID, artist disambiguation, etc.
Wanted your feedback on whether this would be something useful and considered/reviewed for inclusion?
Thanks in advance for looking.
Noticed MusicBrainz support is sort of implemented with the MB tags cached in CSong. I was taking a look into writing an MB scraper and I noticed that the scrapers only get the Artist/Album as strings. I took a look at the code behind the MusicScanner & MusicScraper and wondered if you would be open to discussion & patches to the music scraper?
I looked at a couple of approaches to propogate MBIDs to the scrapers in the code, but my thought finally was to do the following - open to feedback:
1) I would propose to add the fields MusicBrainzArtistID -> 'artist'/CArtist, MusicBrainzAlbumID & MusicBrainzAlbumArtistID -> 'album'/CAlbum in MusicDatabase->AddSong. While I was writing this I realised this has a secondary advantage - later we can disambiguate similar named Artists/Albums etc using the strArtist & MBArtistID as the key on Artist. But in the first instance the proposal is just to propogate these fields to the Artist/Album to keep it simple. There would be issues around similar named artists but I think those same issues exist today so we're not breaking anything existing.
2) For MusicInfoScanner and MusicDatabase:
My proposal is to pass a CAlbum, CArtist, etc to DownloadAlbumInfo/DownloadArtistInfo and downstream functions instead of fixed strings strAlbum and strArtist. This way any members of the CAlbum & CArtist structs can be passed to scrapers. Later if we extend those structs it is easier to get that data to the scrapers (no refactoring the function params each time). For those source functions calling e.g. DownloadArtistInfo with only a string we'd first create a CArtist, and populate it with all of the data we have in hand. The scrapers could get more of the data available to us in order to make less amiguous decisions. With MBIDs in CArtist & CAlbum as above, we can now easily pass the scanned MBIDs to the scraper.
I have working patches to do 1) and I'm just working on part 2) of the change as a proof of concept. I notice also the MBID tags on my m4as aren't being scanned in right now, I will check that out too.
Finally this would require additional scrapers that key off MBID not 'Artist Name' etc.
I think all of this would be great for fanart.tv which already seems to key of MBID, artist disambiguation, etc.
Wanted your feedback on whether this would be something useful and considered/reviewed for inclusion?
Thanks in advance for looking.