[peel] State of play

[Riving Ton]

Wow!
Well done Steve and Alasdair for taking the time to summarise the state of play.
Alasdairs's file naming essay might be considered boring by some folk I'm sure but it is a well thought out and presented guide to a protocol we should be adhering to. (I'll be amazed if we manage to present 400+ tape digitisations in this format!).
I agree that sessions' information is unnecessary - the data could be presented as an additional track-listing file or we can simply consult Ken's bible!
DeeDee



----- Original Message ----
From: Alasdair Macdonald <wewalkforonereason@...>
To: peel@yahoogroups.com
Sent: Thursday, July 31, 2008 12:15:28 PM
Subject: Re: [peel] State of play


2008/7/31 saipanda <saipanda@yahoo. com>:
> Hi folks,

> Peel yyyy/mm/dd (session artists)

Windows filenames can't have slashes in them. The preferred
international date format these days is *ISO8601, which is CCYY-MM-DD.

http://en.wikipedia .org/wiki/ ISO_8601

NOT CCYYMMDD, or CCYY.MM.DD or any variation thereof.

In some operating systems case is significant, so "peel" is different
from "Peel". In addition, under some circumstances spaces in filenames
and file paths may be problematic.

Therefore the 2 options are probably:

PeelCCYY-MM- DD
or:
peelCCYY-MM- DD

There's no need for any additional information in the filename except
perhaps the source. Often times sources that match etree database
entries are identified as follows:

gd1980-08-17. sbd.miller. 93037.sbeok. flac16

In this example, the details are available here:
http://db.etree. org/shninfo_ detail.php? shnid=93037

sbd identifies the source (eg audience or sb)
miller identifies the person that prepared or circulated the material
sbeok identifies that the files are cut correctly for CD burning
flac16 identifies the format and sample size
93037 - the number in the middle - is the id and enables further
details to be accessed on the etree website.

Since the broadcast source and etree id are all but redundant [unless
the recording details were to be stored on etree], a peel recording
could be identified as follows:

(for side A) - "peel1981-12- 01.rocker. a.flac"
(for side B) - "peel1981-12- 01.rocker. b.flac"

If there is a requirement to include the "internal" id used (for
instance to apply to rocker's tapes), then that could be used too:

peel1981-12- 01.id-goes- here.rocker. a.flac
peel1981-12- 01.id-goes- here.rocker. b.flac

(There wouldn't be any need to specify flac16, since anyone that
chooses to digitise an FM>cassette source to 24 bit is likely insane).
I am assuming that 44k is the standard sample rate to be used; I don't
know if there is any demand for 48k.

mp3 filenames would obviously match:
peel1981-12- 01.rocker. a.mp3
peel1981-12- 01.rocker. b.mp3

The text file and md5 file and/or ffp file use the same naming convention:
peel1981-12- 01.rocker. txt
peel1981-12- 01.rocker. ffp
peel1981-12- 01.rocker. md5

The name that comes between the date and format should probably used
to identify the person who performed the digitisation. For instance,
person A may perform a flawed digitisation, and when it is redone by
person B, there is then a clear way of identifying which source is
which.

peel1981-12- 01.rocker. a.flac
peel1981-12- 01.doofus. a.flac

I don't collect or listen to old Peel shows - it's only the sessions
that interest me - but there is also a question of tracking. If these
are stored and shared as individual flac files per show (or per
cassette side), then the files are quite large, but easy to
"transport", because they are fewer in number.

On the other hand, complete (or even incomplete) shows that are
tracked are more likely to raise issues of copyright, since they are
more explicitly copyright thefts.

If we have, for instance:

peel1981-12- 01.rocker. t01.flac
peel1981-12- 01.rocker. t02.flac
peel1981-12- 01.rocker. t03.flac
peel1981-12- 01.rocker. t04.flac
peel1981-12- 01.rocker. t05.flac

and tracks 01, 03 and 05 are JP links, and t02 is an unreleased
session track, and t04 is a commercially issued recording, then the
fileset facilitates copyright theft to an extreme degree. At least
with shows that are archived in large, single files, the copyright
issue is obfuscated by the presentation of the show as a whole as a
single item of legitimate historical interest. Furthermore, there are
fewer concerns with recordings being cut to CD sector boundaries (for
those who wish to burn to CD) if the recordings are shared as large
.flac files (covering an entire show, or side of a cassette).