JimC;290406 Wrote: > The idea isn't broken, and it may well be how this "problem" gets solved > in the end. However, it adds a layer of complexity to the process and > we're already being dinged for being too hard for the average user. >
Since I'm watching SqueezeCenter evolution, I learnt that any change could be far more complicated than it seems at first sight, and I know that "more simplicity" is now the leitmotiv of SC evolution. That's why I think of the need of a predefined set of templates easy to use without strong understanding of what lies beneath and set by default to the most common behavior (ie present SC behavior). But for sure, the way I describe isn't the easiest way to deal with the problem. It could (even only partially implemented) be the only way to please everybody. JimC;290406 Wrote: > > What we need is the most sensible default rules (which I think we may > already have, Mr. Sinatra's opinions/issues notwithstanding), and a > reasonable method for changing those. I would really like to avoid > moving these types of settings to the SC interface, because they would > require a rescan; much better to do them upfront, if possible. > To keep it simple, if the only thing is to deal with is this BAND/ALBUMARTIST problem adding a single option like "emulate itunes broken BAND tag behavior" tick box could do the trick... (that's the user interface point of view, implementation is a different problem). To be honest, I learned to use SC "as is" for basic pop/rock browsing and to use Erland plugins for classical music... so I'm not really concerned nor very knowledgeful about this TPE2/BAND/TPXXX problem :). JimC;290406 Wrote: > > I'd love to see what you're working on, and would encourage you to > contribute it to the code base here. There are some pretty amazing > programmers (both here and in our community) that you would be able to > work with on the framework and on the code. My team and I would be > happy to provide input, as well, at least from a product > marketing/customer-centric viewpoint. > Since the beginning I have "open source" and "community" in mind. There's no doubt I will publicly share most of my work (except for restricted data connector like AMG). But as I need this work for my own music, I want it quickly (ok, more than six months have passed since I began to work on this:) ), and I'm not sure I want to spend the little free time I have to work on this with dozens pages of arguments about how to handle "band" and "album artist" ;). I already talked here of tagging problems I had, and a little about this "metadata framework" I'm working on, but SNR are sometimes too high on forums to be efficient. Furthermore, everybody has its own problems and its own little tools and tricks not wanting to change its habits (the only true generic tools I know are Erland's wonderful plugins). As no software/hardware handle tags the same way, I decided that metadata cannot be stored in standard tags and soon concluded that metadata had to be kept away from media files. I thought to a central repository holding all metadata, but I wasn't pleased with this idea as music is moved, copied, transfered, renamed, etc. I've decided that metadata would be "album centric". Assuming that every album is stored in its own folder (or set of subfolders like disc1, disc2, etc), each "album folder" can easily contain a single xml file with the corresponding metadata (it's looks like sfv files). The concepts that guided me are: - limit manual input to the minimum (only typing data at the hierarchical level needed: album, group of tracks (work), or track - store the data for what they really are, not for what they are going to be in music files (handle composer as composer, not "album artist" because you want to browse it) - be versatile enough to adapt to different level of complexity according to the user personnal needs - keep tagging for the end of the process, so that it's always possible to "batch retag" a full collection (when you change your mp3 hardware, or your media management program) - include some little tricks/automation to ease handling data like: generic aliases (making data uniform by considering "Bach", "JS Bach", "Bach, J.S." are the same and are all tagged "Johan Sebastian Bach"), sort name guessing, opus and catalog extraction from classical work titles, etc. To be more practical, this "metadata framework" consist of: - a complex data model defined with XSD (xml was my goal, but it could be anything else from txt file, to sgbd, passing by yaml). This data model can be used in a simple way (to represent data like in FreeDB: album artist, album name, tracks name) or in a complex way (It is designed to be compatible with AMG and Discogs data model... right now I still have to check if it can also fit Amazon model) - a Perl library to handle this data model in memory, and serialize/deserialize it in xml files - a set of DataSource plugins (to get data from Discogs, Amazon, FreeDB, cduniverse, etc.) to fill xml - a set of DataExporter plugins that can tag mp3 files, tag flac files, print a report, etc. Right now, I have beta versions of these four components (more a Proof Of Concept needing perl coding to be used, than a real ready-to-use tool, but I'm using it), and I'm working on some kind of graphical interface to make it friendly and accessible before it's released. (you can have to wait another six months as after having to learn perl again in the beginning of this project, I now have to learn tk widgets tkx programming:) ). -- vrobin ------------------------------------------------------------------------ vrobin's Profile: http://forums.slimdevices.com/member.php?userid=11705 View this thread: http://forums.slimdevices.com/showthread.php?t=46093 _______________________________________________ discuss mailing list discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
