Philip Meyer;290932 Wrote:
> >The discussion of tags and their interpretation is entirely different
> to
> >the main problem, there are too many developers here who are missing
> the
> >other, and more important problem: usability.
> >
> I'm sorry, but I disagree. I believe developers are very conscious of
> usability, and do a good job of catering for all people. I don't
> believe there is a big problem with usability. Whilst I sympathise
> with you about your problem (I'll try to help), it is a different
> problem to the one discussed in this thread.
> ...
>
Hi Philip.
It does indeed look like this thread is becoming too broad to be
effective, and that there are a lot of various issues with tagging that
concern a customer. I'm deliberately not going to use a term 'average',
'typical' 'advanced' e.t.c., just a customer - person who doesn't need
to concern themselves with the internal workings of SC.
However, I'm assuming here that anybody with complex tagging needs
would be willing to separate tagging as a step in 'music obtaining
process', use dedicated tagging program and do some custom tagging.
While I'm sure that developers do their best to make very usable code,
they will do it within the bounds of their musical interests,
experiences and musical collections, probably do the testing the same
way and slowly drift off. Surely, there are people in SC's customer
base who's needs (or wants) are more complex than what the developers
could imagine.
So, how about creating some form of case study - a separate thread
(best in 'ripping/tagging' forum) that would discuss various tagging
scenarios and provide solution(s) to the best approach? Ideally, make
it a sticky and set up some rules how to present a scenario and how to
suggest a solution. Maybe make somebody powerful enough to go in there
from time to time and swipe the noise. If we find some scenario that
doesnt' have good solution, then raise a ticket or enhancement request.
I wouldn't mind making serious contribution there as I have a library of
a couple of thousands meticulously tagged classical tracks and there I
have encountered most of the real world scenarios one is likely to
hit.
Now, back to the internals of the code. There are two things that are
purely developers prospective/error (IMO) here that I could see going
through the code:
- scanner. Last time I mentioned that its functionality to recognize
changed tracks isn't good enough - does it solely based on file update
date vs last scan date. I suggested doing it also based on size,
archive attribute or checksum. Well, going through the code, surprise,
surprise - there's a comment there that states:
# When rescanning: we need to find files:
#
# * That are new - not in the db
# * That have changed - are in the db, but timestamp or size is
different.
A code following it handles timestamp but not size. So they even knew
that there was a problem but for some reason choose not to solve it.
- concept and handling of 'track artist' contributor type. Basically,
if there is ALBUMARTIST defined for the album, then all ARTISTs become
trackartists. There is no connection between the guy who is ARTIST on
one and trackartist on another album. It is not possible to flow (or
drill down) in SB menu system from trackartist to artist. Now, that
might be how the code works, but from real world prospective makes
little sense.
K
--
slimkid
The sound stage will open up, bass will tighten and the imaging will
improve. DVD performance will also increase substantially.
http://www.youtube.com/watch?v=7iAj2aPdQnk
http://www.youtube.com/watch?v=VvMNuuFSvN0
http://www.youtube.com/watch?v=BDRhRv4q_SI
http://youtube.com/watch?v=nlrpe8Ig5m8
http://youtube.com/watch?v=dC9tGlwPln8
------------------------------------------------------------------------
slimkid's Profile: http://forums.slimdevices.com/member.php?userid=8881
View this thread: http://forums.slimdevices.com/showthread.php?t=46093
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
