LISTSERV mailing list manager LISTSERV 16.0

Help for ARSCLIST Archives


ARSCLIST Archives

ARSCLIST Archives


ARSCLIST@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

ARSCLIST Home

ARSCLIST Home

ARSCLIST  January 2016

ARSCLIST January 2016

Subject:

Re: A case in point why CDText should have been used for metadata from Day 1

From:

Mark Donahue <[log in to unmask]>

Reply-To:

Association for Recorded Sound Discussion List <[log in to unmask]>

Date:

Thu, 7 Jan 2016 10:12:50 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (98 lines)

Tom,
One or two quick comments.
The first I saw of CDText in the mastering business was around 2004-5. You
supplied a .bin file on a floppy with your 1630 master and Sony DADC was
the only one doing it. It was crude and only allowed for 2000 characters
total.
A few years later when the 1630 went the way of the Dodo along with most of
the old replication hardware, we started encoding CD+Text info on all
masters supplied for replication. Most of the record companies immediately
stripped this information out during replication. Warner was still doing
this as late as 2005.
All the best,
-mark

On Thu, Jan 7, 2016 at 9:47 AM, Tom Fine <[log in to unmask]> wrote:

> Hi Shai:
>
> My understanding is that CDText was always available in Red Book. It
> doesn't matter what the original players could display, that's my point.
> Anyone who was using a Commodore or Apple computer in the early CD era
> could see where media was going. Metadata was going to be very important to
> digital media. My contention is, by surrendering control of their metadata,
> the CD producers, owners, manufacturers and sellers surrendered a key part
> of marketing -- clear, uniform explaination of the product. Depending on
> booklet text and/or physical packaging was short-sighted. To this day, the
> metadata released from the record companies to such massive retail forces
> as Amazon are inconsistent, often confusing and often incomplete, because
> it's usually a job left to interns and clerks instead of being a topline
> responsibility of project producers. This is a really important discussion
> that should have been had at the beginning, but should still be had. It
> would behoove the copyright owners to come up with standards and release
> all media going forward with uniform naming of artists, songs, etc, and
> uniform formats for how to express, for instance, classical works'
> movements or other track-title information.
>
> And by the way, the sloppy metadata has now spread into the streaming
> services, because they just use the same gobbledygook that is on Amazon and
> iTunes. If we want "the kids" to use music as something beyond background
> noise, it is necessary for them to have a clear understanding of what they
> are listening to. In the purely digital realm (streaming and downloads),
> the only clue beyond sound is good metadata.
>
> -- Tom Fine
>
> ----- Original Message ----- From: "Shai Drori" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Thursday, January 07, 2016 9:34 AM
> Subject: Re: [ARSCLIST] A case in point why CDText should have been used
> for metadata from Day 1
>
>
>
> Tom, you're forgetting that the original red book didn't even have a
> provision for the text addition. Players were very crude with just a four
> digit numerical display that could show time or track. All the other
> additions that came later were additions that some players were not even
> aware of. Case in point, the CD can actually be 4 channel from day one
> (part of the red book), but have you ever seen a 4 channel CD or player? On
> the other hand there was never the foresight to change bit depth or sample
> rate. Can you imagine what the CD road map would look like if there was a
> provision for 20 or 24 bit recordings and even 88.2kHz sample rate? And
> yes, the original authoring software was terrible. I still remember by
> heart most of the PQ code rules for track placement and spacing. I'm more
> of an old fart than I care to admit. haha 😉
> Cheers
> Shai Drori
>
> On Thu, Jan 7, 2016 at 3:45 PM, Tom Fine <[log in to unmask]>
> wrote:
>
> The 1995 Smithsonian collection "Big Band Renaissance: the Evolution of
>> the Jazz Orchestra" is a great example of group-source metadata FUBAR.
>> dBPowerAmp's CD ripper program allows use of multiple metadata sources,
>> and
>> by default does some sort of amalgam of whatever sources you've told it to
>> check. The amalgam on this set is comical! So I manually checked metadata
>> from each source. They are all different, and only GD3 (whatever that is)
>> is anywhere near accurate. I find this often happens with compilations --
>> for instance freedB and/or AllMusic will have different top-level stuff
>> like titles and whether or not it's a compilation for different individual
>> CDs in the same box set.
>>
>> All of this could have been prevented if the industry embraced CDText from
>> the get-go and agreed on uniform naming standards for artists and song
>> titles. I remember the arguments back in the 80's --  it's hard enough to
>> enter PQ codes into these balky Sony editing systems, and no CD players
>> have displays for CDText, so why bother. Very short-sighted. The net-net
>> today is that anyone who wants uniform naming and accurate information in
>> a
>> digital library has to spend a lot of time editing the crappy metadata
>> that's out there in group-source land. And, copyright owners have ceded
>> control of their metadata to a group-source no-QC cluter-you-know-what.
>>
>> -- Tom Fine
>>
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Error during command authentication.

Error - unable to initiate communication with LISTSERV (errno=111). The server is probably not started.

Log In

Log In

Get Password

Get Password


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager