Text 3172, 160 rader
Skriven 2005-03-17 12:46:32 av Glenn Meadows (1:379/45)
Kommentar till text 3171 av Chris (1:379/45)
Ärende: Re: Programmers help needed.
====================================
From: "Glenn Meadows" <gmeadow@comcast.net>
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.
--
Glenn M.
"Chris" <nospam@noemail> wrote in message news:4239c918@w3.nls.net...
> More questions....
>
> 1) How much data are you talking about here overall? If it is not THAT
> huge, then Access might be the simplest choice. With Access, as you know,
> you can export data in xls, csv, xml and other formats.
>
> 2) How many people need to access this data at one time and how often is
> this data accessed? If you have many people who need access to the db at
> once, then a centralized db server might be a better choice, especially if
> there is a lot of data. Another consideration for centralized db servers
> is what centralized db server software you have now and the experience
> level of the admins who will manage that db wrt the db software and
> SQL/Report programming.
>
> 3a) How often does this data need to be exported?
> 3b) How does the client need this data delivered to the other companies
> (email, ftp download, http download, other means of delivery, snail mail
> <ugh>)?
> 3c) Can this process be automated?
>
> 4a) Are the companies willing to accept the data in xml format versus
> other formats (xls, csv, txt, et al.)?
>
> 4b) As Adam asked, are the companies able to fish out duplicates and other
> data errors and still import your data successfully and in the manner you
> expect?
>
> 5) How long do you have to develop this database? (In other words, what's
> the project's timeline?)
>
> 6) What kind of user interface is needed for initial data entry and
> ongoing data entry, db management functions?
>
> Ok, I'm out of questions, but, at first glance, I would consider Access. I
> understand Access better than the other software out there. It's also
> more user-friendly for many people than something like SQL Server or
> mySQL. I have no experience with FileMaker.
>
> Btw, is the comcast email address in your header a valid one that you
> check? If not, email me. My domain is k7sle.com and the email address is
> chris@.
>
> Thanks,
>
> /Chris
>
>
> Glenn Meadows wrote:
>> Answers to questions:
>>
>> 1). I'm double checking, but I think that 1 file per CD is required. At
>> one point, Napster said just add to the bottom of the xl spread sheet. I
>> think all would LIKE and XML form, but some accept an XL spreadsheet,
>> grudgingly.
>>
>> 2). Oh, anything. We've got FileMaker Pro here, and there is the
>> ubiquitous Access. Again, this is a TOOL we use to generate this data
>> one time, since once the product is on a service, it's unlikely we'll
>> need to generate that info for that service again. It might be necessary
>> if other services come online (a likely scenario), so the ability to
>> locally craft the style of output needed for a new service would be a
>> requirement. So, essentially, we're looking at a source database, and a
>> report generator that allows us to pick the data needed, and the order
>> it's to be placed, and the format of the output of that report.
>>
--- BBBS/NT v4.01 Flag-5
* Origin: Barktopia BBS Site http://HarborWebs.com:8081 (1:379/45)
|