Text 3221, 122 rader
Skriven 2005-03-20 16:56:00 av Ellen K. (1:379/45)
   Kommentar till text 3184 av Adam (1:379/45)
Ärende: Re: Programmers help needed.
====================================
From: Ellen K. <72322.1016@compuserve.com>

Yes, this is the current way to go, except that I still disagree about using
CSV for the folks who require Excel.   However, Office 2003
already speaks XML so there should be a way to do it that way.

On Fri, 18 Mar 2005 14:14:40 +0000, Adam
<acompletemystery@somewhere.org> wrote in message <423ae1cd@w3.nls.net>:

>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)