Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 4 of 4
  1. #1
    Pat Farrell
    Guest

    Re: Strawman SQL database integration thoughts

    At 07:55 PM 8/12/2004, Dale E Martin <dmartin (AT) cliftonlabs (DOT) com>
    > wrote:
    >Not if we have the same album, but mine is remastered and yours isn't.
    >Then will have the same album, same songs, same tracklist, etc and we still
    >won't be able to automatically say "the same song" by comparing bytes.


    By my working definition, remastered versions are different songIDs.

    >Perhaps this is a pathological case,


    I don't think it is pathological at all.
    There are many different releases of CDs, especially
    hyper popular rock from the 60s and 70s that the
    labels want to resell over and over.

    > I think the point is that calculating a
    >primary key off of the data will cause more troubles that it's worth.


    If all you are saying is you don't want it to be the primary key,
    that is fine with me. Use an autoincrement generated key
    as the primary, and store the hash in the main table.

    What I care about is identifying songs that are identical and have
    it be independant of path, meta data, tags, etc. so we can add
    data linked in from other sources.

    Pat

  2. #2
    Dale E Martin
    Guest

    Re: Re: Strawman SQL database integration thoughts

    > If all you are saying is you don't want it to be the primary key, that is
    > fine with me. Use an autoincrement generated key as the primary, and
    > store the hash in the main table.


    I can buy that. I'll be interested to see if the hash is useful in real
    life or not. I use cdparanoia and lame and that is way more effort than
    many people I know go to to rip their CDs. I would think it would be very
    rare to end up with the same bytes for the same record of the same song -
    but I happily admit that I could be wrong here.

    Take care,
    Dale
    --
    Dale E. Martin, Clifton Labs, Inc.
    Senior Computer Engineer
    dmartin (AT) cliftonlabs (DOT) com
    http://www.cliftonlabs.com
    pgp key available

  3. #3
    Will McDonald
    Guest

    Re: Re: Strawman SQL database integration thoughts

    On Thu, Aug 12, 2004 at 10:32:40PM -0400, Dale E Martin wrote:
    > I can buy that. I'll be interested to see if the hash is useful in real
    > life or not. I use cdparanoia and lame and that is way more effort than


    I'm not sure about this either; I agree that there's very little cost to
    storing a hash in the DB, but I think that in general, this won't identify
    many dupe songs (at least in my ~60GB collection). I have all my music indexed
    in an SQL DB, and it's almost always a human decision to say "these two
    recordings of a song can be considered 'identical'", because different copies
    of a song almost always come from different CDs, or I downloaded a single off
    the net years ago and just got the CD.

    What is much more useful to me (and probably wouln't be in the default
    slimserver implementation, although I'd like to extend the DB to handle this)
    is having a column called "hasError". If I'm listening to music and notice
    that the track cuts off prematurely or has clicks and pops in it, I jump on
    my laptop and set that flag. This makes it really easy to see what songs I
    should re-rip or re-download, and would make it easy to tell slimserver to not
    play any songs with known errors.

    BTW, I like the distinction between a "song" and a "performance" made earlier,
    and re relative properties of each. I seperate artists vs performers in my DB,
    but I hadn't split up "song". Thanks!

    -w

    --
    ---------Will McDonald-----------------will (AT) u...T) cs.wisc.edu----------
    GPG encrypted mail preferred. Join the web-o-trust! Key ID: F4332B28

  4. #4
    Jack Coates
    Guest

    Re: Re: Strawman SQL database integration thoughts

    ....
    > What is much more useful to me (and probably wouln't be in the default
    > slimserver implementation, although I'd like to extend the DB to handle
    > this)
    > is having a column called "hasError". If I'm listening to music and notice
    > that the track cuts off prematurely or has clicks and pops in it, I jump
    > on
    > my laptop and set that flag. This makes it really easy to see what songs I
    > should re-rip or re-download, and would make it easy to tell slimserver to
    > not
    > play any songs with known errors.
    >

    ....

    ding, good idea there -- should be tied to the Zap feature (holding Add
    during playback).
    --
    Jack At Monkeynoodle.Org: It's A Scientific Venture...
    "Believe what you're told; there'd be chaos if everyone thought for
    themselves." -- Top Dog hotdog stand, Berkeley, CA

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •