Sabtu, 15 November 2014

Re: [MS_AccessPros] Song Database

 

Hi Jerry,

I started building a song database too.  About 6 years ago, I created a program to generate a list of songs for a friend who was a karaoke DJ.  Reports to print by Song and Artist were printed and bound.  I made 20 songbooks for her to pass out to the singers. 

Karaoke files are a zip file with 1. MP3 file with audio and 2. CDG file with text overlay.  I my Listfiles program to read the drives and discs with songs and used to populate a database with file information from the ZIPs. 

ListFiles Database
by and modified by Crystal
http://www.accessmvp.com/strive4peace/DB_ListFiles.htm
 
Bill Mosca gave me code to unzip so I looped and split the zips.  I then wrote a program to read metadata from MP3 files using methodology published by Doug Steele.  It was specifically for MP3 files though.

After that was written, Wayne Phillips posted a tool to read metadata from any file in any format, which would be useful for you to get:

Accessing detailed file information provided by the Operating System
  by Wayne Phillips

Since I then had all that information in a database, I was compelled to do more with it.

Because I am a songwriter, I then took that information and expanded the data structure to track music structure such as chords and rhythm, which was entered manually from printed music (I play piano and have lots of sheet music and song books).  I also marked Top 40 songs and when they hit.  It was a lot of work and fun! ... but alas, I realized it would take a long time to get it done and I had to make money so I put it on the back burner, where it still is.  Perhaps we could collaborate.  I have > 100,000 song records -- many are duplicates so the unique songs are probably more around 40,000.  I was in the process also of identifying the duplicates.

I agree with John that you need to separate out the different participants in the song.  I would, however, suggest a Roles table and a Persons (or Contacts) table, and a cross-reference table with SongID, RoleID, and PersonID.  

Then, for instance, when you find that the lyrics were written by someone other than a composer, you could simply add another role.

I would suggest getting my contacts template and expanding it to track your song info.  Remove the extra business tables in there that you don't need.  The contacts template has other features like Anywhere Notes, Anywhere Attachments, and Lists that wold be useful as you are entering information.

To learn about the contact template, watch this video:

and then go get the download here:

Each contact can be linked to websites and other information so when the same contact participates in more than one song, information about the contacts need only be entered in one place.

What is your motivation to do this?


Warm Regards,
Crystal

 *
   (: have an awesome day :)
 *



On Saturday, November 15, 2014 9:46 AM, "John Viescas JohnV@msn.com [MS_Access_Professionals]" <MS_Access_Professionals@yahoogroups.com> wrote:


Jerry-

Think about all the subjects you need and the relationship between them.

Here's a starter list:

Songs
Composers
Artists
Albums
CopyrightHolders

Because Songs can have multiple Composers and each Composer writes multiple songs, you need a Many-to-Many relationship.  To do that in a relational database, you need what I call a "Linking" table - SongsComposers.

A similar relationship exists between Songs and Artists - you need a SongsArtists table, and that linking table probably should also contain a link to Albums.

I assume a CopyrightHolder can have multiple Songs, but can a Song have multiple CopyrightHolders?

You may also need a Performances or Tracks table.  I can imagine that a particular Artist or combination of Artists might perform the same song multiple times, but on different albums.  Maybe some live performances as well as studio.  And the length for each Song-Artist performance or track might be different depending on the album or venue.  A Tracks table would then contain the SongID, ArtistID, AlbumID, perhaps venue, and Length.

Does that help?

John Viescas, Author
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
SQL Queries for Mere Mortals
http://www.viescas.com/
(Paris, France)




On Nov 15, 2014, at 5:26 PM, Jerry bearjercares@gmail.com [MS_Access_Professionals] <MS_Access_Professionals@yahoogroups.com> wrote:

Greetings -

I am working on a master song database with potentially thousands of
songs linked to discographies, copyright holders and the like.  My
question right now is (I'm sure I'll have more later):

1.  Some songs have multiple composers.  Should I set up a table from
which to get the authors into the master song index and what is normally
the easiest or best way to handle when there are multiple authors?

Thanks!
Jerry Boor, Michigan, USA


------------------------------------
Posted by: Jerry <bearjercares@gmail.com>
------------------------------------


------------------------------------

Yahoo Groups Links







------------------------------------
Posted by: John Viescas <johnv@msn.com>
------------------------------------


------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/MS_Access_Professionals/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/MS_Access_Professionals/join
    (Yahoo! ID required)

<*> To change settings via email:
    MS_Access_Professionals-digest@yahoogroups.com
    MS_Access_Professionals-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
    MS_Access_Professionals-unsubscribe@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/



__._,_.___
Posted by: Crystal <strive4peace2008@yahoo.com>
Reply via web post • Reply to sender • Reply to group • Start a New Topic • Messages in this topic (3)

.

__,_._,___
Diposting oleh di

Tidak ada komentar:

Posting Komentar

Langganan: Posting Komentar (Atom)