[Nepomuk] Music issues I want to fix
Ignacio Serantes
kde at aynoa.net
Wed Jun 13 14:00:29 UTC 2012
Well, I forgot classic music so I was wrong :P.
nmm:albumPerformer, with a cardinality 0:n is totally right. It's not
handled by id3 tags but for classic music is in several cases the main
difference between two music albums.
On Wed, Jun 13, 2012 at 12:18 PM, Ignacio Serantes <kde at aynoa.net> wrote:
>
>
> On Wed, Jun 13, 2012 at 11:27 AM, Sebastian Trüg <sebastian at trueg.de>wrote:
>
>> On 06/13/2012 11:04 AM, Ignacio Serantes wrote:
>>
>>> Hi,
>>>
>>> On Wed, Jun 13, 2012 at 10:52 AM, Sebastian Trüg <sebastian at trueg.de
>>> <mailto:sebastian at trueg.de>> wrote:
>>>
>>> On 06/10/2012 08:32 PM, Ignacio Serantes wrote:
>>>
>>> I brief update status.
>>>
>>> 1) I just fix multiple performers bug in flac analyzer.
>>>
>>> 2) nmm:albumArtist seems to be related to DB structure and is not
>>> a
>>> coding bug. I just added nmm:albumArtist to SDO and now there is a
>>> nmm:albumArtist in nmm:MusicAlbum. This is the code I added:
>>> nmm:albumArtist
>>> a rdf:Property, nrl:DefiningProperty ;
>>> rdfs:subPropertyOf nco:contributor ;
>>> rdfs:label "album artist" ;
>>> rdfs:comment "Album artist" ;
>>> rdfs:domain nmm:MusicAlbum ;
>>> rdfs:range nco:Contact .
>>>
>>>
>>> This looks good. I am only concerned about having performer and
>>> producer on the tracks and artist on the album. Shouldn't that be in
>>> sync somehow? After all an album is also produced, right? A
>>> compilation has a producer and each track has a possibly different
>>> producer...
>>>
>>>
>>> This is right but as there is no tag for album producer this information
>>> can not be obtained from the music file so this is outside my actual
>>> goals. Album producers can be obtained using a query, as I'm doing in
>>> Nepoogle for album performers.
>>>
>>
>> What I mean is we need nmm:albumProducer and nmm:albumPerformer. What do
>> you think?
>>
>
> nmm:albumProducer don't bothers but I'm not sure about nmm:albumPerformer.
> Performer is the "performer" and not the album artist, yes my Engrish is
> bad. An album artist is a good field because and album always have an
> associated artist: Queen, ELO or Various artists, but in the real world
> there is not a performer associated with the album but is associated to
> music piece.
>
> Album producer is not the same case because, sometimes, there is a general
> album producer and other producers for music pieces. So album producer and
> artist producer are the same case but not for performers, lyricists or
> composers. It's right that many times performers, lyricist or composers are
> the same for all the music album but I still consider that this are music
> piece fields.
>
>
>
>>
>>
>>>
>>>
>>> I will upload a patch to Review Board for the first one but,
>>> what must I
>>> do with the second one?
>>>
>>>
>>> The normal approach is to create a ticket at
>>> https://sourceforge.net/apps/_**_trac/oscaf/<https://sourceforge.net/apps/__trac/oscaf/>
>>>
>>> <https://sourceforge.net/apps/**trac/oscaf/<https://sourceforge.net/apps/trac/oscaf/>
>>> >
>>>
>>>
>>> Ok, thank you. I will add a ticket.
>>>
>>>
>>>
>>> On Thu, Jun 7, 2012 at 7:59 PM, Ignacio Serantes <kde at aynoa.net
>>> <mailto:kde at aynoa.net>
>>> <mailto:kde at aynoa.net <mailto:kde at aynoa.net>>> wrote:
>>>
>>> Hi,
>>>
>>> I detect next issues with music albums scanning flac and mp3
>>> formats:
>>>
>>> 1) Performers:
>>>
>>> * mp3: supports it but it wrongly adding nmm:albumArtist
>>> too and
>>>
>>> this must be related to nmm:MusicAlbum.
>>> * flac: only adds one performer, the last added to the
>>> file?.
>>>
>>> nmm:musicArtist it's not imported and an error is
>>> launched:
>>> "Cannot set values for abstract property
>>> 'http://www.semanticdesktop.__**org/ontologies/2009/02/19/nmm#**
>>> __albumArtist
>>> <http://www.semanticdesktop.**org/ontologies/2009/02/19/nmm#**
>>> albumArtist<http://www.semanticdesktop.org/ontologies/2009/02/19/nmm#albumArtist>
>>> >'
>>> <http://www.semanticdesktop.__**org/ontologies/2009/02/19/nmm#**
>>> __albumArtist
>>>
>>> <http://www.semanticdesktop.**org/ontologies/2009/02/19/nmm#**
>>> albumArtist<http://www.semanticdesktop.org/ontologies/2009/02/19/nmm#albumArtist>
>>> >'>.".
>>>
>>> Solution:
>>>
>>> * 0 to n nmm:albumArtist resources must be added to
>>> nmm:MusicAlbum.
>>> * 0 to n nmm:performer resources must be added to
>>> nmm:MusicPiece.
>>>
>>>
>>> 2) Albums:
>>>
>>> * there is no url in nmm:MusicAlbum so two different
>>> albums with
>>>
>>> same name are considered one unique resource.
>>> * determine album url is tricky, you need to obtain the
>>> url from a
>>>
>>> track, a method complicated because previous problem.
>>>
>>> Solution:
>>>
>>> * add nie:url to albums.
>>> * two albums with same name but different path are different
>>>
>>> albums. This have a side effect with sets if sets are in
>>> different paths, but I think is better that sets are
>>> considered
>>> different albums, than two different albums are the same
>>> resource. On the other side, this could be handle with
>>> some
>>> smart path detection assuming some kind of organization
>>> with
>>> paths. Other solution could be using nmm:albumArtis to
>>> determine
>>> if two albums are different but, then we have the
>>> problem with
>>> various artists compilations.
>>> * added nfo:depiction as a cover, an image that could be
>>> handled
>>> by Bangarang or Nepoogle.
>>> * maybe more nfo:depiction for scans?
>>>
>>>
>>> 3) Genres:
>>>
>>> * mp3: is not working.
>>> * flac: works fine, supporting unlimited genres.
>>>
>>> Solution:
>>>
>>> * bug with mp3 files must be fixed.
>>>
>>>
>>> 4) Sets:
>>>
>>> * there is no total tracks per set.
>>> * the total tracks is equal to the total tracks number in
>>> the last
>>> track scanned.
>>>
>>> Solution:
>>>
>>> * a solution similar as seasons in tvshows.
>>> * a total tracks and a total tracks per set must be handled.
>>>
>>>
>>> I'm only using flac and mp3 so the same or other issues
>>> could be in
>>> other music formats.
>>>
>>> Sets problems is a minor issue, but the other three, must be
>>> fixed.
>>>
>>> As practically all my music is in flac format I will try to
>>> fix
>>> problems 1 and 2 in flac analyzer, I'm crossing my fingers
>>> because
>>> is C++, but I wish to hear comments/suggestions before begin
>>> to code.
>>>
>>> --
>>> Best wishes,
>>> Ignacio
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>> Ignacio
>>>
>>>
>>>
>>>
>>> ______________________________**___________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org <mailto:Nepomuk at kde.org>
>>> https://mail.kde.org/mailman/_**_listinfo/nepomuk<https://mail.kde.org/mailman/__listinfo/nepomuk>
>>> <https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>> >
>>>
>>> ______________________________**___________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org <mailto:Nepomuk at kde.org>
>>> https://mail.kde.org/mailman/_**_listinfo/nepomuk<https://mail.kde.org/mailman/__listinfo/nepomuk>
>>>
>>> <https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Best wishes,
>>> Ignacio
>>>
>>>
>>>
>>>
>>> ______________________________**_________________
>>> Nepomuk mailing list
>>> Nepomuk at kde.org
>>> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>>
>> ______________________________**_________________
>> Nepomuk mailing list
>> Nepomuk at kde.org
>> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>
>
>
>
> --
> Best wishes,
> Ignacio
>
>
>
--
Best wishes,
Ignacio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120613/81c755eb/attachment.html>
More information about the Nepomuk
mailing list