Text 3184, 113 rader
Skriven 2005-03-18 14:14:40 av Adam (1:379/45)
   Kommentar till text 3172 av Glenn Meadows (1:379/45)
Ärende: Re: Programmers help needed.
====================================
From: Adam <acompletemystery@somewhere.org>

OK then a few mini pointers:

A) Build a simple db structure which contains the superset (i.e. all the info
you can capture) consisting of common (i.e. sql92) fields such as varchar so
that in the future the backend will be portable.

B) Get a routine which exports XML as per the above structure (i.e. keep it
simple) such you have a basic single XML file as an export

C) Then use XSLT to format the XML file to suit a given useage/partner. This
could be used for multiple uses including being able to turn your catalog into
XML, PDF, HTML, CSV etc.etc. etc.etc.


Adam


Glenn Meadows wrote:

> 1). In the long run, it will eventually be our entire catalog of CD's as we
> add older content to the online stores.  That's a constant and ongoing
> process.  Right now, the slow down, is providing all this detailed info, and
> having to do it again and again, with different sets of the same data.  Some
> services want song writers, publishers, publisher percentage spits, others
> don't want the splits.  If everyone used the same protocol as Apple does in
> iTunes Producer (special program to provide content to that store), it would
> be really easy.  Fill in the blanks, and go.  Since WE pay the royalties
> from our percentage of the sale, Apple doesn't NEED or request the
> publishing/writer info, since it has no need for that.  That would be like
> Tower wanting the publishing info on every CD that they sold.  Not needed.
>
> 2). Probably only 2 or 3 at a time entering the info into the database, and
> only in one local office on a local lan.
>
> 3a).  Each CD, once for each online service, and for each new one that might
> come along and want their own format (we'd set up one for each service
> anyway, just to make sure it was the way they wanted it).
>
> 3b). Typically some electronic form to accompany the physical CD.  We send a
> CDR with the graphics file, so we'd put the metadata file on the same disk.
> We typically consolidate all the files for a shipment of product on one CD
> that covers the specific CD's that are in a shipment.  It might be 5-20
> releases, depending on what we're ready to upload.  Having this in some easy
> to export system, would speed up the sending of the info to the other end a
> whole bunch.
>
> 3c). Automated as in how/what?  Input of the data?  At this point, too many
> diverse sources for the info.  We're moving it to one document at the
> moment, Word, since we need a hard copy of that form for every release and
> file.  There's a product folder, that has copies of the contract, etc.  On
> this form, is the full label copy, tray card copy, publishing info, lists of
> territories we have distribution rights in, where the sources of the audio
> came from (original mixes, compiled from prior releases).  This is used to
> link into our Royalties database, where royalty rates are configured based
> on the specific contract that controls that composition, and uses the price
> of the release to set the percentages that are paid when royalty statements
> are run.
>
> 4a).  That remains to be seen.  Some say EITHER XML or XL spreadsheet, and
> setup specific formats for both that they want the data in, so that they can
> suck it into their systems.
>
> 4b).  I assume so, they send an email, or make a phone call if something is
> amiss.  We've already had one service that had 4 artists from another label
> being reported as our revenue, "operator error" on their part, they claim.
> It was fixed within a day of it's discovery.
>
> 5). Whenever we get it proposed, and approved.  It's "timely", but not a
> deal breaker at this point, just a major bottleneck in getting the content
> available online.  We've seen tremendous growth in the online revenues, but
> NOTHING that would sustain or support a label at this point.  Growth is
> good, we just need to feed the engines that promote the growth.  People
> can't buy it, if it's not in the stores.  It's not just a simple job of
> rip/post, especially when you consider the massive number of releases to
> make available.  Everyone is scrambling.
>
> 6). Probably just a simple data entry screen with the places to enter the
> info for each track, so you initially have the global info of the CD (title,
> artist, etc), then you have the specific track detail, then a button for ADD
> A TRACK, or FINISH, so you can keep entering data for a disk.  ALso have to
> deal with multi-disk sets, as well.
>
> This is a major headache for all the independants that feed the online
> services, as all of this typically falls to the the little guys (small
> labels) to do if we want to play.  For example, Apple does the encoding for
> all the major labels, all they do is send the CD and label copy, Apple does
> the rest.  For the indies, the provide the software, and you do the work,
> and upload to the store.
>
> In many respects, I wish the other services would do that as well, provide
> the software to do the encoding.  Apple allows you to either import from a
> file, or rip from the CD. If importing from files, we could create WAV files
> for every CD, then use each companies software to convert the fils to the
> format/bitrate that they want, enter the data, and upload the finished
> package to their stores.  I'm pushing for that, but so many have made deals
> with outside companies to "do the work", that there's too much money
> involved.  We'd gladly setup a bank of machines to do the encoding/uploading
> IF we could get an encoding package from the services.  iTunes Producer
> creates the MP4 files, creates the XML data sheet, and sends it in one
> upload to the Apple store.  Then the DRM (yea, I know, evil stuff, but you
> live with what you got to live with) is added as part of the download sent
> to the buyer (or it's added prior to going into the store, I don't know the
> real sequence).
>
> Yes, the email address at comcast.net is a valid email address.
>
>
>

--- BBBS/NT v4.01 Flag-5
 * Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)