PDA

View Full Version : Archiving classics



ovonrein
2005-11-05, 05:40
Folks, I am looking for simple advice here:

Since the SB2 now offers native support for gapless playback via FLAC, I have started to move my classical music collection onto the PC - and I have hit an archiving wall:

It seems quite clear from the various PC music players on offer (SlimServer just being a case in point) that these tools were invented by folks who primarily listen to pop music.

In pop music, most people equate the artist to the composer, or simply do not care for the latter.

This does not work for classical music. When starting my classic music archive, I have taken to assigning the composer name to the artist tag (shunting the artist into the comments). This considerably facilitates retrieval through the artist/album focussed SB2 interface.

But this is still unsatisfactory. Like many classic buffs, I suspect, I have the same piece of music recorded by various artists, in which case the concept breaks down.

What do you guys do?

Prefixing the artist name to the song title is do-able, but the eternal scrolling on the player display that invariably follows is ever so slightly tedious.

In general, I was wondering whether some future piece of SS s/w could perhaps offer to configure an extra directory level (for the composer) in the music library?

Also, I would find it helpful if the access to album and artist in the player interface could be pre-filtered by my choice of genre.

If I go into genre at the present time, I automatically end up accessing the sub-level by artist. What if I wanted Album? Composer?

Thanks - ovr.

Iain Bason
2005-11-05, 07:02
I just got my squeezebox, and am facing the same issue. I haven't yet figured out what to do about it. I suppose I could always modify the software. Is there a good high level overview of the software design?

ovonrein
2005-11-05, 08:04
Well, if you want to go to that length, you should join the developer circle. And I shall look forward to your modifications. Bon courage.

Bart
2005-11-05, 08:42
...these tools were invented by folks who primarily listen to pop music
and so they still refer to every track as a "song"

stinkingpig
2005-11-05, 09:05
ovonrein wrote:

>...
>But this is still unsatisfactory. Like many classic buffs, I suspect,
>I have the same piece of music recorded by various artists, in which
>case the concept breaks down.
>
>What do you guys do?
>
>
....
Use the Composer tag when you tag your files. Some tag and rip programs
don't offer it, but it is there and Slimserver will use it.

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

pfarrell
2005-11-05, 09:51
On Sat, 2005-11-05 at 04:40 -0800, ovonrein wrote:
> Folks, I am looking for simple advice here:

But your problem, which is shared by many, is not simple.
My collection is stored using the pop-oriented genre/artist/album/...
tree.


> What do you guys do?


I use softlinks to point to both
classical/beethoven/ninth_symphony_d_minor and
classical/muti/beethoven 9th in D minor

It is not a great solution, but its easy

It doesn't address your real concerns, please keep reading....

> I have hit an archiving wall:
>
> In pop music, most people equate the artist to the composer, or simply
> do not care for the latter.
>
> This does not work for classical music. When starting my classic music
> archive, I have taken to assigning the composer name to the artist tag
> (shunting the artist into the comments). This considerably facilitates
> retrieval through the artist/album focussed SB2 interface.

I'm unclear why you are calling this an archiving problem. Perhaps
I don't understand what you are calling archiving.

I see three separate and almost unrelated design questions:

1) how are tracks stored in the physical disk? What structure makes
sense?

2) how are tracks tagged? and

3) how are groups of tracks managed?

The key problem is that any hierarchical structure fails for
classical music.

So the clear solution is to design a system that lets you answer #1 with
"any way you want, its not important". Separate storage from access.
Then focus on managing access.


> In general, I was wondering whether some future piece of SS s/w could
> perhaps offer to configure an extra directory level (for the composer)
> in the music library?

Extra directories can be setup by you now. But that won't
do much, as it is hierarchical thinking that is the root problem.

While hierarchical databases were widely used in the 70s and 80s,
they have completely fallen out of favor because lots of problems
have the same structural difficulties as classical music in a pop world.

The alternative to hierarchical databases for the past 30 years has
been a relational data base than can locate information independently
of how it is stored, and in ways that change without requiring major
restructuring.

Lucky for SqueezeBox fans, the major thrust of the 6.* series releases
of the SlimServer uses a relational database as the store for all meta
data (meta data here meaning data about the important data, with
artist, title, composer being metadata pointing to a wad of music bits
that we want to hear.

Which brings us back tot he answer for my last two questions:
2) how are tracks tagged? and
3) how are groups of tracks managed?

For me, the answer to #2 is again, use anything that is consistent
within your library, but don't lose much sleep over it. The concept of
tagging software is too closely tied to pop music and while extensions
and non-standard approaches can help, the reality is that the limits
of internal tags become painfully clear with classical. So just tag
the files basically and move on.

The real solution is to use external data to manage the collection.
Data that is in a relational database. A database with extensions
so that there are clear and easy to use fields like
conductor, soloists, accompanists, group, and performance-location for
the recording and composer, title, movement, key, opus etc.
for the music.

This is not far off. But there is some work to be done.
Most obviously is that when we have lots of data from sources
not in the tags for the song, processes like scanning the library
can not glibly throw away the existing database. And upgrades to
the software and data schemas have to be aware of existing data
and provide migration tools.

None of this was possible without the huge effort to make 6.* work.
Now that the database version is settling down, the additions
become just a SMOP. (small matter of programming).



--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Wendy Seltzer
2005-11-05, 10:48
On 11/5/05, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
>
> On Sat, 2005-11-05 at 04:40 -0800, ovonrein wrote:
>
>
> > What do you guys do?
>
>
> I use softlinks to point to both
> classical/beethoven/ninth_symphony_d_minor and
> classical/muti/beethoven 9th in D minor


I remap the tags.
"Artist" = composer,
"Album" = work, and
"Title" = performers, as soloist(s) - conductor (orchestra).

I also join all the movements of a piece into a single file, which has the
side benefit of making randomized play work more effectively. So my
directory for the same recording would look like
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Muti.flac

This loses some information about movement boundaries and what disc a
performance came from, but I find it makes navigation much more convenient.

--Wendy
(also searching for the elusive "best way" to catalogue classical)
--
Wendy Seltzer
http://wendy.seltzer.org/blog/

pfarrell
2005-11-05, 11:09
On Sat, 2005-11-05 at 12:48 -0500, Wendy Seltzer wrote:
> I also join all the movements of a piece into a single file, which has
> the side benefit of making randomized play work more effectively. So
> my directory for the same recording would look like
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Muti.flac

Does this lead to
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Toscanini_BBC.flac
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Toscanini_LaScala.flac
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Mengelberg.flac
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_Cleveland.flac
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_London.flac
symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_Columbia.flac

Now the 9th is one of the worst cases, everyone has recorded it at
least once. But the conductor and orchestra and often the vocal chorus
all deserve to be part of the identifying indicies. And maybe
you'd want to listen to how the LSO plays the first movement under
the direction of Muti, Szell and Toscanini.

> (also searching for the elusive "best way" to catalogue classical)

To be followed up with which is the best recoring of the 9th :-)

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

ovonrein
2005-11-05, 11:26
Use the Composer tag when you tag your files. [...] Slimserver will use it.

What for? Yes, you can dig deep into the tags on your Slim player to find out, but that's not the point. It is the music tree that would require the extra level to search on.

ovonrein
2005-11-05, 11:55
I use softlinks to point to both
classical/beethoven/ninth_symphony_d_minor and
classical/muti/beethoven 9th in D minor


It's a thought, I grant you. And it's one I can actually follow.



I see three separate and almost unrelated design questions:

1) how are tracks stored in the physical disk? What structure makes
sense?

2) how are tracks tagged? and

3) how are groups of tracks managed?


Agreed - to some extent.



The key problem is that any hierarchical structure fails for
classical music.


You lost me with this one. I had thought that

Composer/Work/Artists/Movements

pretty much covers all bases. I am not too bothered mixing singers and conductors in the Artists component.



Extra directories can be setup by you now. But that won't
do much, as it is hierarchical thinking that is the root problem.

The alternative to hierarchical databases for the past 30 years has been a relational database.


Yes, and I have seen more chaos in relational databases than I ever saw in hierarchical structures. Relational database design tends to require more discipline than the average designer cares to muster. Hierarchical databases usually impose it.

Oh and - granted - there is the *odd* problem that could indeed not be elegantly represented in hierarchical form ;)



For me, the answer to [tagging] is again, use anything that is consistent within your library, but don't lose much sleep over it. The [...] reality is that the limits of internal tags become painfully clear with classical. So just tag the files basically and move on.


I am with you on that once since from what I can make out, the Slim player interface only allows me to retrieve by file tree structure. Tags come in later, when it comes to building the playlist.



The real solution is to use external data [...] in a relational database. A database with extensions so that there are clear and easy to use fields like conductor, soloists, accompanists, group, and performance-location for the recording and composer, title, movement, key, opus etc. for the music.


You are beginning to lose me. I can only surmise that you are proposing that my search should be able to traverse an arbritrary number of attributes.

The Slim player interface will adapt, since it will simply follow these branches.

This would work.

And I am sure that you can make it work in your modern-day relational database. Only SMOP. As a small aside, I had thought that you would have found a hierarchical database a much more natural choise - they adapt too, you know ... :)

Michaelwagner
2005-11-05, 11:59
I think Pat is going in the right direction here.

The layout of the files on disk storage is essentially independent of everything else.

Yes, I know you can drill down the tree with the slim interface, or with windows explorer (or ls if you're a *nix fan), but fundamentally you're doomed. What was important to me 4 years ago when I started recording music on my hard disk is not what is important to me now. And in 2 years I'll be interested in other stuff. I am neither going to move all that music into new branches, nor am I going to re-record it all.

It's not just classical music.

I'm very interested in folk music. I have a large collection in storage of Eastern European folk music on records (remember, vinyl). One day when I have nothing better to do with myself, I'm going to dust off that old record player, figure out how to get audio in into MP3 format, and record it all. And then what?

Let's say I have this tune that originated in Bulgaria, but the Turks liked it so they put Turkish lyrics to it. Gypsies moved it around for 50 years, and this recording is from an ethnically Hungarian band who collected it while visiting a predominantly German town in Transylvania (once the eastern part of Hungary, but now politically Roumania).

If I try to build a storage tree that imparts "information" by where in the tree the song is stored, I'm doomed. Not every example is this complex, but do I store this by country of origin of the tune, of the lyric, of the (majority of the) band members, of the band leader, of the place where the recording was made? And where exactly was it made? Is that place Hungary? Roumania? Translyvania? That depends on when it was made. Some linear tree combining the best aspects of each? It's unknowable ahead of time what requirements might develop over time.

About the only good rule is don't pick a flat structure (the most obvious one) because most major operating systems at the moment can't manage one big directory of 40,000 songs well.

After that, in the MP3 world, there are tags (I don't know about other music formats, because I haven't ventured there yet). The most recent version of the MP3 tagging "spec" includes the following tags of relevance to this discussion:

4.10 COMM Comments

4.2.1 TALB Album/Movie/Show title
4.2.2 TCOM Composer
4.2.3 TCON Content type
4.2.2 TEXT Lyricist/Text writer
4.2.2 TIPL Involved people list
4.2.1 TIT1 Content group description
4.2.1 TIT2 Title/songname/content description
4.2.1 TIT3 Subtitle/Description refinement
4.2.3 TLAN Language(s)
4.2.2 TMCL Musician credits list
4.2.3 TMED Media type
4.2.3 TMOO Mood
4.2.1 TOAL Original album/movie/show title
4.2.5 TOFN Original filename
4.2.2 TOLY Original lyricist(s)/text writer(s)
4.2.2 TOPE Original artist(s)/performer(s)
4.2.2 TPE1 Lead performer(s)/Soloist(s)
4.2.2 TPE2 Band/orchestra/accompaniment
4.2.2 TPE3 Conductor/performer refinement
4.2.2 TPE4 Interpreted, remixed, or otherwise modified by
4.2.5 TSOA Album sort order
4.2.5 TSOP Performer sort order
4.2.5 TSOT Title sort order
4.2.2 TXXX User defined text information frame

The complete list is here (and, while not perhaps exhaustive, is exhausting to look through):
http://www.id3.org/id3v2.4.0-frames.txt
Scroll down to section 4.

Now, Slim can read all these tags. At the moment, though, it doesn't put them all into the database, but you can file enhancement requests with Slim to get your favorite tags supported in a way that makes sense to you, and you can influence how Slim prioritizes doing the work by getting your friends and fellow music followers to vote for the enhancements.

Michaelwagner
2005-11-05, 12:06
What for? Yes, you can dig deep into the tags on your Slim player to find out, but that's not the point. It is the music tree that would require the extra level to search on.I think something is missing here.

As of 6, what you are browsing, when you start from the home page of the web interface to slim, is not directory based but tag based. When you select "Browse Albums", artists, artwork, genres, years, you are browsing by the tag content of those files.

Only when you select "Browse Music Folder" are you going into the physical music tree.

(the other ones, below - New Music, Favorites, Random Mix, Playlists - are implemented in other ways)

pfarrell
2005-11-05, 12:22
On Sat, 2005-11-05 at 10:55 -0800, ovonrein wrote:
> pfarrell Wrote:
> >
> > The key problem is that any hierarchical structure fails for
> > classical music.

> You lost me with this one. I had thought that
> Composer/Work/Artists/Movements
> pretty much covers all bases. I am not too bothered mixing singers and
> conductors in the Artists component.

Its all just personal preference. you propose
> Composer/Work/Artists/Movements

but I'd probably go with

>
> pfarrell Wrote:
> >
> > Extra directories can be setup by you now. But that won't
> > do much, as it is hierarchical thinking that is the root problem.
> >
> > The alternative to hierarchical databases for the past 30 years has
> > been a relational database.
> >
>
> Yes, and I have seen more chaos in relational databases than I ever saw
> in hierarchical structures. Relational database design tends to require
> more discipline than the average designer cares to muster. Hierarchical
> databases usually impose it.
>
> Oh and - granted - there is the *odd* problem that could indeed not be
> elegantly represented in hierarchical form ;)
>
> pfarrell Wrote:
> >
> > For me, the answer to [tagging] is again, use anything that is
> > consistent within your library, but don't lose much sleep over it. The
> > [...] reality is that the limits of internal tags become painfully
> > clear with classical. So just tag the files basically and move on.
> >
>
> I am with you on that once since from what I can make out, the Slim
> player interface only allows me to retrieve by file tree structure.
> Tags come in later, when it comes to building the playlist.
>
> pfarrell Wrote:
> >
> > The real solution is to use external data [...] in a relational
> > database. A database with extensions so that there are clear and easy
> > to use fields like conductor, soloists, accompanists, group, and
> > performance-location for the recording and composer, title, movement,
> > key, opus etc. for the music.
> >
>
> You are beginning to lose me. I can only surmise that you are
> proposing that my search should be able to traverse an arbritrary
> number of attributes.
>
> The Slim player interface will adapt, since it will simply follow these
> branches.
>
> This would work.
>
> And I am sure that you can make it work in your modern-day relational
> database. Only SMOP. As a small aside, I had thought that you would
> have found a hierarchical database a much more natural choise - they
> adapt too, you know ... :)
>
>
--
Pat Farrell
http://www.pfarrell.com

pfarrell
2005-11-05, 12:32
On Sat, 2005-11-05 at 10:55 -0800, ovonrein wrote:
> pfarrell Wrote:
> > The key problem is that any hierarchical structure fails for
> > classical music.
> You lost me with this one. I had thought that
> Composer/Work/Artists/Movements
> pretty much covers all bases. I am not too bothered mixing singers and
> conductors in the Artists component.

Its all personal preference. You like Composer/Work/Artists/Movements
where I would tend to prefer: /Genre/Composer/Artist/Work/Movements

But I really don't want it to be hierarchical. Composer -> Work is fine,
we all agree on that, but even something as simple as Genre is far
too vague to be a major hierarchical divider. Some folks want
to consider "Classical" as one genre (i.e. the NullSoft folks who
brought you MP3 tags) yet anyone with a even modest sized classicial
collection would distinguish between baroque, romantic, modern and
post-modern.

Sometimes the conductor matters, sometimes not, but the big
conductors work with many of the major symphonies, you can't
assume that Riccado Muti is always with Philly.


> pfarrell Wrote:
> > The alternative to hierarchical databases for the past 30 years has
> > been a relational database.

> Yes, and I have seen more chaos in relational databases than I ever saw
> in hierarchical structures. Relational database design tends to require
> more discipline than the average designer cares to muster. Hierarchical
> databases usually impose it.

Lets not go into theology here. I'll grant that the easy of use allows
people who are clueless to design terrible relational schemas.

The fact is that SlimServer starting with 6.0 has a relational database
back end. We are using it, we can use it to do more.



> pfarrell Wrote:
> >
> > The real solution is to use external data [...] in a relational
> > database. A database with extensions so that there are clear and easy
> > to use fields like conductor, soloists, accompanists, group, and
> > performance-location for the recording and composer, title, movement,
> > key, opus etc. for the music.
> >
>
> You are beginning to lose me. I can only surmise that you are
> proposing that my search should be able to traverse an arbritrary
> number of attributes.

Since we have a database, and a front end, you can use the predefined
interface. Or, since it is all open source, we can build upon
what is there and add a few columns.

Back to theology, there is no requirement to expose the database,
and proper code will simply ignore columns and tables that it
doesn't know about. This is something that no hierarchy can handle.


> And I am sure that you can make it work in your modern-day relational
> database. Only SMOP.

Way smaller now that all the heavy lifting has been done for us.

We've got it, we might as well use it.

--
Pat Farrell
http://www.pfarrell.com

Wendy Seltzer
2005-11-05, 12:52
On 11/5/05, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
>
> On Sat, 2005-11-05 at 12:48 -0500, Wendy Seltzer wrote:
> > I also join all the movements of a piece into a single file, which has
> > the side benefit of making randomized play work more effectively. So
> > my directory for the same recording would look like
> > symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Muti.flac
>
> Does this lead to
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Toscanini_BBC.flac
>
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Toscanini_LaScala..flac
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Mengelberg.flac
>
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_Cleveland.flac
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_London.flac
>
> symphonic/Beethoven,_Ludwig_van/Symphony_No._9_in_d_min/Szell_Columbia.flac


Yes, or even
Beethoven,_Ludwig_van/Symphony_No._9_in_D_minor/Harnoncourt_(Chamber_Orchestra_of_Europe).flac
Beethoven,_Ludwig_van/Symphony_No._9_in_D_minor_op._125/Karajan_-_Janowitz,_Rossel-Majdan,_Kmentt,_Berry_(Berlin_Philharmonic).flac
Beethoven,_Ludwig_van/Symphony_No._9_in_d_minor/Haitink_-_Price,_Finnila,_Laubenthal,_Rintzler_(Concertgebo uw).flac
....

when the names are entered inconsistently.


--Wendy

--
Wendy Seltzer
http://wendy.seltzer.org/blog/

pfarrell
2005-11-05, 13:05
On Sat, 2005-11-05 at 14:52 -0500, Wendy Seltzer wrote:
> Yes, or even
> Beethoven,_Ludwig_van/Symphony_No._9_in_D_minor/Harnoncourt_(Chamber_Orchestra_of_Europe).flac
> Beethoven,_Ludwig_van/Symphony_No._9_in_D_minor_op._125/Karajan_-_Janowitz,_Rossel-Majdan,_Kmentt,_Berry_(Berlin_Philharmonic).flac
> Beethoven,_Ludwig_van/Symphony_No._9_in_d_minor/Haitink_-_Price,_Finnila,_Laubenthal,_Rintzler_(Concertgebo uw).flac
> ...
>
> when the names are entered inconsistently.

And for me, they are always entered inconsistently.
I find that CDDB/FreeDB does OK for pop, but is close to
useless with Jazz and far worse with all the kinds
of classical stuff.

Fixing all this stuff is hard, Especially knowing that
Symphony_No._9_in_D_minor_op._12 and Symphony_Number_9_in_d_minor
are the same is hard to automate, which is why
it is important to not lose all the corrected and additional
metadata just because you install a new release of the SlimServer.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Michaelwagner
2005-11-05, 18:28
it is important to not lose all the corrected and additional metadata just because you install a new release of the SlimServer.Why would you lose metadata? If it's stored in tags in the file, it's not going anywhere.

Or did I miss something?

pfarrell
2005-11-05, 18:38
On Sat, 2005-11-05 at 17:28 -0800, Michaelwagner wrote:
> pfarrell Wrote:
> > it is important to not lose all the corrected and additional metadata
> > just because you install a new release of the SlimServer.

> Why would you lose metadata? If it's stored in tags in the file, it's
> not going anywhere.
> Or did I miss something?

You missed that the metadata is often not sufficient.
Depending on what version of which standard, you may have
what is needed or may not.

There are many advantages of having the metadata in the file,
the biggest is that once it is right, you can move the file
without worry.

But the ID3 specs, which are not well standardized and not
nearly universally implemented, were completely pop oriented. They have
slowly evolved to be less terrible for classical music, but many of the
tools haven't kept up. And ID3 isn't the solution for flac or ogg files.
Getting both the id3 and ogg tag definitions and tools to be
defined and implemented is not something that I'm willing to
hold my breath on.

I'm not sure that it is even possible to get reach a consensus
on what fields are important in the classical world.

But this is an opportunity. The database can do what ID3 and
ogg tags can never hope to do. Its really not
that hard now that there is a SQL database hidden
behind the SlimServer


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Michaelwagner
2005-11-05, 18:57
So, Pat, are you advocating that Slim maintain it's own file of extra-meta data to make up for the lack of sufficient tags in MP3 and OGG?

pfarrell
2005-11-05, 19:27
On Sat, 2005-11-05 at 17:57 -0800, Michaelwagner wrote:
> So, Pat, are you advocating that Slim maintain it's own file of
> extra-meta data to make up for the lack of sufficient tags in MP3 and
> OGG?

I'm advocating using the database and not being cavalier about deleting
it. The file exists and is usually called .slimserversql.db

I'm not so much pointing to lack of goodness in the existing tag
as saying that we've got a relational database, the tags can't
do what I need, so it makes sense to use the relational database.

I'm also saying that since we have a database, there is no reason
to think that the hierarchical file structure should be important
to the management of the data.

There is a lot more of the rationale for the design in the dev-list
archives from the early days when we were designing what needed
to be in 6.0.0. I posted a straw-man schema and justification for it.
Lots of it was accepted, some was not, but open source development
is collaborative, I wasn't the king.

Adding fields (attributes, columns, whatever you want to call them)
is easy. It will solve problems in many areas.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Michaelwagner
2005-11-05, 19:44
I think you'd have to store such things somewhere else. The Slim software is far too quick to clear the database.

It's one button push. Or one software failure. Too easy to lose.

Perhaps a second meta file in the same directory as the song file? With your own tags that don't fit into the MP3 scheme (yet). Slim could be taught to read those as well.

Works better for backing up the data too.

pfarrell
2005-11-05, 19:56
On Sat, 2005-11-05 at 18:44 -0800, Michaelwagner wrote:
> I think you'd have to store such things somewhere else. The Slim
> software is far too quick to clear the database.
> It's one button push. Or one software failure. Too easy to lose.

I agree that the SlimServer process has to stop assuming that the
database is valueless. I expect a preference can fix the server
clobbering it so quickly. There are other implications
that were covered long ago, things like how you tell if a songfile
is the same or not. Cryptographic hashes handle this easily
at a cost of more CPU for each scan. So folks with underpowered
servers will not want to enable the preference.


>Perhaps a second meta file in the same directory as the song file? With
>your own tags that don't fit into the MP3 scheme (yet). Slim could be
>taught to read those as well.

No, this is a very bad idea. it is a global, serverwide collection
of metadata, not something directory specific. But details belong
over on dev-list.

I've mentioned it here because all of the hard work has been done
and many people don't seem to realize that the database is there.
The schemas are in the slimserver directory tree,
/usr/local/slimserver/SQL on my installation.

The standard sqlite front end works well on the database.

Things like proper backup, schema alterations to support
new releases, etc. all will take a small amount of
work.


--
Pat Farrell
http://www.pfarrell.com

JJZolx
2005-11-05, 20:32
But this is an opportunity. The database can do what ID3 and
ogg tags can never hope to do. Its really not
that hard now that there is a SQL database hidden
behind the SlimServer
I follow what you're saying, in that the database could be made more useful, but... If the data associated with a given track (or album) isn't to be found in the tags (or perhaps in a CUE sheet, but let's ignore that for now), then where does it come from? It either needs to be contained in some other form, such as separate text files, or else it needs to be entered manually in SlimServer.

This is where you'd need to begin turning SlimServer into a bonafide music library management system. It would require a user interface, the ability to edit the metadata of multiple files, etc., etc. I'm all for eventually making SlimServer a music manager - in fact I think it's inevitable, but it's a long way off. Given the apparent difficulty right now of performing even simple tasks upon the existing data, I'd guess that's a very _long_ way off.

kdf
2005-11-05, 20:42
On 5-Nov-05, at 7:32 PM, JJZolx wrote:

> Given the apparent difficulty
> right now of performing even simple tasks upon the existing data, I'd
> guess that's a very _long_ way off.
>
I love how there is always a subtle slap in the face slipped in there :)

I'd suggest that the long term problem of the above suggestions would
be the extreme aversion some users have to the idea that slimserver
would be used to enter data of any kind. a pr campaign would have to
be in place to make sure they know it is just the db
-k

pfarrell
2005-11-05, 20:53
On Sat, 2005-11-05 at 19:32 -0800, JJZolx wrote:
> pfarrell Wrote:
> > But this is an opportunity. The database can do what ID3 and
> > ogg tags can never hope to do. Its really not
> > that hard now that there is a SQL database hidden
> > behind the SlimServer

> I follow what you're saying, in that the database could be made more
> useful, but... If the data associated with a given track (or album)
> isn't to be found in the tags (or perhaps in a CUE sheet, but let's
> ignore that for now), then where does it come from? It either needs to
> be contained in some other form, such as separate text files, or else it
> needs to be entered manually in SlimServer.

It does need to magically come from somewhere and get entered into the
database. There are more options than just the two you mention.

Clearly a suitable GUI could let people type it in.
Or cut and paste the data from a good source, something
like allmusic.com

One of the problems that I have is that the current automated
sources, such as cddb or freedb, have terrible data problems.
It isn't too terrible for pop, but it is terrible for
more serious music.

A related problem is how do you tell if the tracks were ripped properly.
The idea behind http://www.accuraterip.com/ is good,
but they are uninterested in non-windows platforms or
any of the concepts of open source. So one solution could
address both issues, invent an open source equivalent to
accurate-rip that also focuses on accurate meta data.
It could provide the magic data feed and validate that
the rip was correct. I've sketched out some of the code
needed to do this.

> This is where you'd need to begin turning SlimServer into a bonafide
> music library management system.

It is my music libary management system. Its not great at it,
but it has been the library management system for my 700+
CDs since I got my first SB1 years ago.


> It would require a user interface,
> the ability to edit the metadata of multiple files, etc., etc.

It has a user interface now. Maybe not suitable or optimized for
generalized management, but that is another SMOP.


> for eventually making SlimServer a music manager - in fact I think it's
> inevitable, but it's a long way off.

I don't see it as a long way off. maybe I'm a hopeless optimist.
Or maybe I've been building web front ends to RDBMS systems
since the early days of the web. A lot of this is not
rocket science.

> Given the apparent difficulty
> right now of performing even simple tasks upon the existing data, I'd
> guess that's a very _long_ way off.

Then again, I have no problem doing fairly complex stuff with 6.2.1
I could have missed it, but I've not noticed a lot of data management
problems on the forums. Lots of installation problems, connection
provisioning, etc. The lost genre problems appear to be fixed fairly
quickly as they are reported. The general regression testing
and reliability issues are best left in one of the existing
threads, or taken over to the dev-list.

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-11-05, 21:41
ovonrein wrote:

>stinkingpig Wrote:
>
>
>>Use the Composer tag when you tag your files. [...] Slimserver will use
>>it.
>>
>>
>>
>What for? Yes, you can dig deep into the tags on your Slim player to
>find out, but that's not the point. It is the music tree that would
>require the extra level to search on.
>
>
>
>

I don't have enough classical in my collection to have a problem, but I
seem to recall some discussion back in the "what should our database
schema be" days about using Composer alongside Artist in the browse and
search pages. So that if you had Composer=Johann Sebastian Bach and
Artist=Lara St. John for one album, then Composer=Johann Sebastian Bach
and Artist=Jakob Lindberg for another album, you'd get three listings in
Browse By Artist. That would be useful, no?

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

ceejay
2005-11-06, 01:50
So, a nice complicated discussion there from everyone, which confirms what we all knew from the beginning - managing classical music (or, I now learn, folk!) is tricky as we are using tools designed for pop. So, there are two branches for this problem:

(1) how do you make the best of what we have (which was one of the original questions in this thread - "what do you guys do")

and

(2) how would we like the system to change to make it better.

To help the OP, I'll add my own answer for Q1, as I found similar feedback from others very helpful when I was trying to get my head round the problem.

First - separate the concept of CD and album. In classical music, an album is a piece of music (eg a symphony). I use a directory structure which corresponds to the CD, so I an reconstruct it if I ever need to, in the style
\musiclib\flac\classical\Beethoven\Beethoven PC 4,5 Arrau

The directory name has only a rough abbreviation of the pieces and enough of the performers to be unique.

Inside the directory I have one track per movement, named like:
Beethoven Piano Concerto 5 in E flat Major, 'Emperor', Op 73 - 1 - Allegro.flac

I've never yet found any satisfactory automated tagging of classical music - I usually let EAC look up in CDDB but end up overwriting almost all of it. Artist tag in this example would simply be "Beethoven". "Album" is tagged like:
Beethoven Piano Concerto 5 in E flat Major, 'Emperor', Op 73 - Arrau - Davis - Staatskapelle Dresden

For Genre, I use multi-valued genre tags, so this one might be
Classical;Romantic;Concerto;Piano

Taken as a whole, I find this system works pretty well for me. The only thing I might do differently if there ever is a next time is to abbreviate slightly more (PC instead of Piano Concerto) to reduce scrolling. Otherwise I can find what I want, when I want it. Random play works as long as you ask for random Albums. I can see the piece details on the screen all the time, and if I want to check the performer details they are not too far away in the menus (just go off to the right to get all the file details).

Moving on to question (2), how could this be better? There is certainly some potential for making use of the database in smarter ways, but IMHO this is a long way off and, as noted previously in this thread, would imply a quite different usage model for Slimserver (becoming more of a music manager), as well as a different idea of how to use the database (right now its considered ok to ask users to trash the database to get round SS problems, this clearly needs a new ooutlook if we're going that way).

So right now I'm happy keeping all my data in the tags where I know its safe, and am just looking for slightly better ways for browsing. For example, either browsing or Random play for a combination of genre tag values ("piano" AND "concerto" for example).

Still, back to Q1, what I have is working well, and I'm very happy with my new toy...

Ceejay

ovonrein
2005-11-06, 04:22
Since we [now] have a database, [...] we might as well use it.


Don't get me wrong, it sounds promising. I am stuck at the moment so anything you can do to improve on that has my blessing ;)

Thanks - ovr.

Michaelwagner
2005-11-06, 07:51
I think an intermediate step, before we go to Pat's full blown database that stores its own stuff, we should make better (full?) use of the MP3 (and other format tags) that are defined today.

Pat (or someone else, don't remember) pointed out that most taggers don't give you access to the full repertoire of MP3 tags (I should really be calling them ID3 tags).

I use Tag & Rename and the latest version of it supports ID3v2.4.0 (the newest version, if you're keeping track). I haven't gone through and checked if it gets them all, but it gets a whole bunch.

The thing is, Slim doesn't make use of many of those tags. I guess it should. I think before we go off in major new directions, it would be much easier and faster to improve on the Slim support for the tags that already exist.

That would be my suggestion, anyways.

radish
2005-11-07, 08:21
So, Pat, are you advocating that Slim maintain it's own file of extra-meta data to make up for the lack of sufficient tags in MP3 and OGG?

OGG/FLAC tags can store any value you want. There is no limited list of tags like ID3, you can add them freely. Thus, all metadata can be in the file, where it belongs. Having that metadata read out into the slimserver db is obviously required for searching, indexing, etc, but the authorititive source should ALWAYS be the file.

geoffb
2005-11-07, 08:32
On 11/6/05, Michaelwagner
<Michaelwagner.1y2yhn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I think an intermediate step, before we go to Pat's full blown database
> that stores its own stuff, we should make better (full?) use of the MP3
> (and other format tags) that are defined today.
>
> Pat (or someone else, don't remember) pointed out that most taggers
> don't give you access to the full repertoire of MP3 tags (I should
> really be calling them ID3 tags).
>
> I use Tag & Rename and the latest version of it supports ID3v2.4.0 (the
> newest version, if you're keeping track). I haven't gone through and
> checked if it gets them all, but it gets a whole bunch.
>
> The thing is, Slim doesn't make use of many of those tags. I guess it
> should. I think before we go off in major new directions, it would be
> much easier and faster to improve on the Slim support for the tags that
> already exist.
>
> That would be my suggestion, anyways.

I agree with Michael here, although I have to say I'm not a classical
buff, in that I don't have enough classical albums to care about who
composed which movement while living in which Eastern European
subcountry.

That said, if all we're wanting to do is (a) store some extra data
about each track and (b) make use of that data in the Slimserver UI,
why not leverage the existing tag options available with MP3 / OGG?
Building and maintaining data separately to the file is always going
to cause unnecessary problems. Does the metadata refer to the music
data by filename (what happens if you want to systematically rename
your music files)? By some ID tag? You then need a UI of some kind
(as discussed) to allow easy manipulation. You then need to train SS
to find and *read* this external metadata.

As far as I know, ID3v2 allows custom tags. Reading and writing *all*
MP3 tags, as well as creating custom ones, is simple with the
excellent, free MP3Tag (under windows - sorry, not sure about *nix).
I don't know enough about FLAC/OGG Vorbis metadata, but perhaps these
extensions would help (I don't know if they were actually
implemented):
http://www.gophernet.org/articles/vorbiscomment.html
Someone who knows about MPC and WMA formats would have to chime in on
solving it for those cases.

>From there, it's matter of DB-persisting the tags as part of the
normal scan process, and presenting menus in the desired sequence in
the SS UI. Something that the SS developers have proven to be
particularly good at.

Cheers
Geoff

Michaelwagner
2005-11-07, 08:35
OGG/FLAC tags can store any value you want. There is no limited list of tags like ID3OTOH, the ID3 scheme has an escape mechanism and extendability, so it is essentially limitless. The only difference in theoretical power between the two approaches is storage consumption, not a big issue these days.

Thus, all metadata can be in the file, where it belongs. I would agree with that. It makes the data portable to another application, etc. But it seems Pat disagrees.

Michaelwagner
2005-11-07, 08:42
I've been through the Slim MP3 tag reading code. It seems to be general enough to read all known tags. It contains a list of tags it's looking for. If they missed some for some reason, it wouldn't be hard to add those.

I haven't checked how it handles the extensible tags yet. That would be a second stage. First I think we should make better use of what it does do (i.e. composer, orchestra, conductor, principal players, etc).

At the next level up, the database is only interested in a select few and ignores the others. But I assume someone with more knowledge than I about the database level could implement the changes needed there.

There is a general mechanism to map the MP3 tags to "standard" names for the higher levels of the slim code. I assume something similar exists in the parallel universes of OGG, FLAC, etc. But I don't know that for a fact.

pfarrell
2005-11-07, 09:01
On Mon, 2005-11-07 at 10:32 -0500, Geoff B wrote:
> That said, if all we're wanting to do is (a) store some extra data
> about each track and (b) make use of that data in the Slimserver UI,
> why not leverage the existing tag options available with MP3 / OGG?
> Building and maintaining data separately to the file is always going
> to cause unnecessary problems.

Extending and providing locally defined tags is clearly one option.
I just don't see that it really solves anything in a particularly
clean way. Suppose you add a tag for "PerformanceLocation" in the
metadata within the file, using suitable ogg/id3v6 format.
What happens with ID3v7 uses the same tag in a different way?

And you have to both tag all your tunes and keep the slimserver
parsing code in sync. Of course, the rules of code reuse encourage
using a normal CPAN library function suite, so now you have
to have your local tags, plus the slimserver plus the CPAN
library all in sync, all with proper upward and downward
compatibility across versions.

> Does the metadata refer to the music
> data by filename (what happens if you want to systematically rename
> your music files)? By some ID tag? You then need a UI of some kind
> (as discussed) to allow easy manipulation. You then need to train SS
> to find and *read* this external metadata.

This points to a key design decision. What is a song?
I proposed in early 6.0 design stages that the file name
is the worst choice for identifying songs. One of
the strengths of the internal tag idea is that you can
copy, rename, move, or even trade songs and still
have it tell you what song it is. File names,
directory structures, etc. get changed all the time,
and changing them should not change the essence of the
song/track/movement/piece.

This raises the question of what is the essence of a song.
When are two songs identical?

There are lots of potential definitions. The most obvious
is that songs are identical if a hash/checksum of the bytes
is identical.

I proposed that we only consider the music part of the file,
and skip all the metadata tags. I think that changing
one of the tags within a song, say Genre from Pop to House
does not change the essence of the music. So I proposed
that we read the whole file, ignore the tags, headers, and
assorted BS, and put the music bytes thru the hash function.
And store the resulting hash.

> Someone who knows about MPC and WMA formats would have to chime in on
> solving it for those cases.

WMA and AAC are great examples of why using tags is not sufficient.
The internal format of these files are proprietary. You may
be able to reverse engineer the format for any specific version,
but you will have to repeat it for each modification that Microsoft
or Apple make.


> From there, it's matter of DB-persisting the tags as part of the
> normal scan process,

I'm convinced that for my needs, no extension of metadata tags
is sufficiently robust to describe all the data and can not
be made applicable to all file formats and versions upward and
downward.

In general database work, information retrieval work, etc.
the separation of data from metadata is well established.
For many good reasons.

I don't understand why so many folks seem to be insisting on
using extended tags. Patches are always welcome. Nothing that
I'm written about prohibits other approaches. There is no
one true way.

I am sure that I'll write the first couple of generations
of patches to implement this. Maybe if folks like it,
they'll use it and encourage the greater developer community
to further enhance it.

I don't see this as needing agreement, we can have it both ways

--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Iain Bason
2005-11-07, 12:18
On Sat, 2005-11-05 at 10:55 -0800, ovonrein wrote:
> pfarrell Wrote:
> > The key problem is that any hierarchical structure fails for
> > classical music.
> You lost me with this one. I had thought that
> Composer/Work/Artists/Movements
> pretty much covers all bases. I am not too bothered mixing singers and
> conductors in the Artists component.

Its all personal preference. You like Composer/Work/Artists/Movements
where I would tend to prefer: /Genre/Composer/Artist/Work/Movements

But I really don't want it to be hierarchical.

--
Pat Farrell
http://www.pfarrell.com

It looks as though people are comfortable with a hierarchical method
of browsing their collections. There's no reason one couldn't
implement it on the server by searching the database for the appropriate
tags, while presenting it to the user as if it's a redundant hierarchy.

In other words, why not present it so you can choose Composer/Work/...
or Artist/Composer/...? Each level of the heirarchy just becomes
a term and-ed to the SQL query.

pfarrell
2005-11-07, 12:23
On Mon, 2005-11-07 at 11:18 -0800, Iain Bason wrote:
> >
> > But I really don't want it to be hierarchical.

> It looks as though people are comfortable with a hierarchical method
> of browsing their collections.

Folks are always more comfortable with what they know. Until
they are shown an alternative that is both painless and
clearly better.

Kinda like how I used to use CD jukeboxes until
I got my first SqueezeBox


> There's no reason one couldn't
> implement it on the server by searching the database for the
> appropriate tags, while presenting it to the user as if it's a redundant
> hierarchy.

Of course. That is what I've been saying in their thread
for quite a while. If you have a real database
you can present it anyway you want.

But if all you have is an hierarchy, then it is
very hard to use or even envision otherwise.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

Josh Coalson
2005-11-07, 14:29
my proposal on how to handle search/browse (comments welcome, that
thread kind of died):

http://forums.slimdevices.com/showthread.php?t=16452

what metadata you want to keep around to display is a separate
problem which is a lot more personal, but solving the search
problem removes a lot of the requirement for metadata structure.

Josh





__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com

Michaelwagner
2005-11-07, 19:27
I don't see this as needing agreement, we can have it both waysA good point.

I could go away and write a complete accessability scheme so that all current ID3 tags are available and browseable at the user interface, and Pat could write a plug-in to store his favorite data, including, I don't know, the name of the driver of the conductor, and there is no conflict and no either/or dichotomy to be resolved.

Michael

Rik
2005-11-11, 00:35
This tread:
http://forums.slimdevices.com/showthread.php?t=17993
is about a related topic, I'd thought to post it here just for convenience. It is about confusing tag names in classical music (ID3 fields "artist/composer" and "album artist").

Rik

stinkingpig
2005-11-11, 17:47
Pat Farrell wrote:...

>There are lots of potential definitions. The most obvious
>is that songs are identical if a hash/checksum of the bytes
>is identical.
>
>I proposed that we only consider the music part of the file,
>and skip all the metadata tags. I think that changing
>one of the tags within a song, say Genre from Pop to House
>does not change the essence of the music. So I proposed
>that we read the whole file, ignore the tags, headers, and
>assorted BS, and put the music bytes thru the hash function.
>And store the resulting hash.
>
>
>
I kinda agree with this in theory, but the practice is not something I
imagine going well.

>>Someone who knows about MPC and WMA formats would have to chime in on
>>solving it for those cases.
>>
>>
>
>WMA and AAC are great examples of why using tags is not sufficient.
>The internal format of these files are proprietary. You may
>be able to reverse engineer the format for any specific version,
>but you will have to repeat it for each modification that Microsoft
>or Apple make.
>
>
>
>

wouldn't the DRM versions of these songs have different checksums on
every device they're copied too?

>>From there, it's matter of DB-persisting the tags as part of the
>>normal scan process,
>>
>>
>
>I'm convinced that for my needs, no extension of metadata tags
>is sufficiently robust to describe all the data and can not
>be made applicable to all file formats and versions upward and
>downward.
>
>
>

XML will solve everything!!! Just kidding, I don't really want to see
any ML used here :)

>In general database work, information retrieval work, etc.
>the separation of data from metadata is well established.
>For many good reasons.
>
>I don't understand why so many folks seem to be insisting on
>using extended tags. Patches are always welcome. Nothing that
>I'm written about prohibits other approaches. There is no
>one true way.
>
>

I'd guess because the tags are often already there, and/or already being
maintained. One could even call them the "standard" since they're the
primary way to get data about songs from one computer music player to
another (even though they all seem to make a database of their own these
days, they're all starting from the tags).

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

pfarrell
2005-11-11, 19:09
On Fri, 2005-11-11 at 16:47 -0800, Jack Coates wrote:
> Pat Farrell wrote:...
> >I proposed that we only consider the music part of the file,
> >and skip all the metadata tags. I think that changing
> >one of the tags within a song, say Genre from Pop to House
> >does not change the essence of the music. So I proposed
> >that we read the whole file, ignore the tags, headers, and
> >assorted BS, and put the music bytes thru the hash function.
> >And store the resulting hash.
>
> I kinda agree with this in theory, but the practice is not something I
> imagine going well.

Can you elaborate? Seems pretty straight forward to me.
It will be kinda slow, but it is an ideal thing to do
in a background thread. The code I wrote to grab
cover art had to be able to read the tags and dictionary
data in MP3 and Flac/Ogg files.


> >WMA and AAC are great examples of why using tags is not sufficient.
> >The internal format of these files are proprietary. You may
> >be able to reverse engineer the format for any specific version,
> >but you will have to repeat it for each modification that Microsoft
> >or Apple make.

> wouldn't the DRM versions of these songs have different checksums on
> every device they're copied too?

I think this is impossible to answer this. You'd have to know
a lot more about the DRM from the assorted vendors than
I know.

I would expect, if they did it "properly" that you
could not access the raw PCM data, so you couldn't
calculate the crypto-hash. Mostly because if I can
get access to the raw PCM data to calculate the hash,
I probably could figure out how to write them
to a file without the DRM.





> I'd guess because the tags are often already there, and/or already being
> maintained. One could even call them the "standard" since they're the
> primary way to get data about songs from one computer music player to
> another (even though they all seem to make a database of their own these
> days, they're all starting from the tags).

I see it more as when all you have is a hammer, all the world's
problems look like nails. Clearly if you focus on moving
tunes to low-brain components, you have to have minimal
common subset approaches, such as tags. But those same
components are not likely to understand or properly
handle any extension or "non-standard" tags.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-11-12, 14:54
Pat Farrell wrote:

>On Fri, 2005-11-11 at 16:47 -0800, Jack Coates wrote:
>
>
>>Pat Farrell wrote:...
>>
>>
>>>I proposed that we only consider the music part of the file,
>>>and skip all the metadata tags. I think that changing
>>>one of the tags within a song, say Genre from Pop to House
>>>does not change the essence of the music. So I proposed
>>>that we read the whole file, ignore the tags, headers, and
>>>assorted BS, and put the music bytes thru the hash function.
>>>And store the resulting hash.
>>>
>>>
>>
>>I kinda agree with this in theory, but the practice is not something I
>>imagine going well.
>>
>>
>
>Can you elaborate? Seems pretty straight forward to me.
>It will be kinda slow, but it is an ideal thing to do
>in a background thread. The code I wrote to grab
>cover art had to be able to read the tags and dictionary
>data in MP3 and Flac/Ogg files.
>
>
>
>

My problem is not about the speed, it's about building a whole new CDDB
type system without leveraging anything else that's already out there. I
have a general problem with starting over from fresh. I also dislike the
idea of putting non-tag-originated information into the database unless
it's being exported and imported somewhere else automatically, as the
database is not a stable source yet. Maybe it will be after porting to
MySQL, but I have my doubts about how smoothly and quickly that will
go... regardless of engine, I wouldn't consider the database stable
until that wipe-and-rebuild button in the server settings can go away :)

>>>WMA and AAC are great examples of why using tags is not sufficient.
>>>The internal format of these files are proprietary. You may
>>>be able to reverse engineer the format for any specific version,
>>>but you will have to repeat it for each modification that Microsoft
>>>or Apple make.
>>>
>>>
>
>
>
>>wouldn't the DRM versions of these songs have different checksums on
>>every device they're copied too?
>>
>>
>
>I think this is impossible to answer this. You'd have to know
>a lot more about the DRM from the assorted vendors than
>I know.
>
>I would expect, if they did it "properly" that you
>could not access the raw PCM data, so you couldn't
>calculate the crypto-hash. Mostly because if I can
>get access to the raw PCM data to calculate the hash,
>I probably could figure out how to write them
>to a file without the DRM.
>
>
>

In other words, this method is incompatible with the stated roadmap:
http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap, bullet 3.

>I see it more as when all you have is a hammer, all the world's
>problems look like nails. Clearly if you focus on moving
>tunes to low-brain components, you have to have minimal
>common subset approaches, such as tags. But those same
>components are not likely to understand or properly
>handle any extension or "non-standard" tags.
>
>
I understand not liking it, but Lowest Common Denominator rules the day.
In my opinion, the ID3 tag needs to remain the primary information store
because the Slimserver is not the only place that these files go; they
will be transferred to and from other music playing systems which will
rely on the tags.

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

pfarrell
2005-11-12, 16:01
On Sat, 2005-11-12 at 13:54 -0800, Jack Coates wrote:
> Pat Farrell wrote:

> My problem is not about the speed, it's about building a whole new CDDB
> type system without leveraging anything else that's already out there.

I haven't proposed any such thing.
But I'm not sure it is all that useful to discuss it, it is probably
time to sling some code.

I see using current tools to rip and compress, which leverage
the good parts of cddb/freedb. But anyone with a serious jazz
or classical collection knows the limits of the cddb/freedb data.
That is what started this thread.


> I wouldn't consider the database stable
> until that wipe-and-rebuild button in the server settings can go away :)

That's the first patch I have to submit to the developers.
The second is a utility to automagically handle schema changes.

And the developers will have to not think of the database as
a cache, which it is now.


> In other words, this method is incompatible with the stated roadmap:
> http://wiki.slimdevices.com/index.cgi?SoftwareRoadmap, bullet 3.

I don't see a conflict here at all.
I'm not interested in dealing with DRMs at all, but that is
a separate thread.

> I understand not liking it, but Lowest Common Denominator rules the day.
> In my opinion, the ID3 tag needs to remain the primary information store
> because the Slimserver is not the only place that these files go; they
> will be transferred to and from other music playing systems which will
> rely on the tags.

I've not proposed getting rid of them. And they will be there
for the iPod of the world.

Think enhancement, not replacement.

But the more important idea is that this is what I've
planned to do since we started talking about 6.0.0 long
ago. Its what I'm gonna do
when I grow up. You don't have to use it.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

stinkingpig
2005-11-12, 16:17
Pat Farrell wrote:

>On Sat, 2005-11-12 at 13:54 -0800, Jack Coates wrote:
>
>
>>Pat Farrell wrote:
>>
>>
>
>
>
>>My problem is not about the speed, it's about building a whole new CDDB
>>type system without leveraging anything else that's already out there.
>>
>>
>
>I haven't proposed any such thing.
>But I'm not sure it is all that useful to discuss it, it is probably
>time to sling some code.
>
>
>
Okay, sorry if I'm reading more into your statements than you've
intended. As you say, it's probably best to go forward with your plan
rather than spend more time trying to explain it.

>
>
>> I wouldn't consider the database stable
>>until that wipe-and-rebuild button in the server settings can go away :)
>>
>>
>
>That's the first patch I have to submit to the developers.
>The second is a utility to automagically handle schema changes.
>
>
>

I do hope you mean a patch to make the database stable rather than a
patch to make the button go away :) Even I could do the latter, but
sadly I and many others still need the button.
....

>Think enhancement, not replacement.
>
>But the more important idea is that this is what I've
>planned to do since we started talking about 6.0.0 long
>ago. Its what I'm gonna do
>when I grow up. You don't have to use it.
>
>
>

Cool -- I look forward to trying it out.

--
Jack At Monkeynoodle Dot Org: It's A Scientific Venture!
"I spent all me tin with the ladies drinking gin
so across the Western ocean I must wander" -- trad.

pfarrell
2005-11-12, 16:39
On Sat, 2005-11-12 at 15:17 -0800, Jack Coates wrote:
> >> I wouldn't consider the database stable
> >>until that wipe-and-rebuild button in the server settings can go away :)
> >
> >That's the first patch I have to submit to the developers.

> I do hope you mean a patch to make the database stable rather than a
> patch to make the button go away :) Even I could do the latter, but
> sadly I and many others still need the button.

What do you mean it seems stable to me. So far at least, it does what I
want.

A separate topic is how to use MySql instead of sqlite.
I see the schemas in the source code, and assume there is a suitable
config parameter that says which to use. But after decades of
using assorted DBMS packages, they all kinda look the same to me.

Another topic worthy of a separate thread is general documentation
of the slimserver's use of the database. It maybe somewhere,
but I haven't found it, yet.

What I expect do start with is an option on the server that says
something along the lines of
"the user has data that is not from the tags, don't just
whack all the data without thinking"

Not to say that sometimes a whack after thinking a bit is
unjustified, sometimes a whack is needed.


--
Pat Farrell
http://www.pfarrell.com