Re: [Tracker] [RFC] Adding CUE sheet support

[Sam Thursfield <ssssam gmail com>]

On Tue, Aug 16, 2011 at 12:26 PM, Philip Van Hoof <philip codeminded be> wrote:
> On Tue, 2011-08-16 at 11:26 +0300, Ivan Frade wrote:
> > Hi!
> >
> > On 8/15/11, Sam Thursfield <ssssam gmail com> wrote:
> > > Hi!
> > >
> > > A lot of people these days have CDs stored as one big .FLAC file, with
> > > a .CUE sheet listing the offset of each actual track. To get Tracker
> > > to recognise these requires some sort of ontology addition to express
> > > the track offsets. As far as I can see, the best solution is the
> > > following: each logical track is a nmm:MusicPiece resource with its
> > > nie:uri pointing to the one .FLAC file, and a new
> > > nfo:audioContainerOffset property that specifies the offset in samples
> > > of the track into its file.
> >
> >  What about adding an anchor/parameters in the URI? Somehow those
> > positions in the stream sound like "anchors" in a URL.
> >
> >  As a norm, is not good to encode information in the URI but in this
> > case could make sense.
>
> It's even necessary in this case, as nie:url is a Inverse Functional
> Property, meaning that it must be unique.

I did like the idea of the URL with a fragment, but now I realise how
much extra data the FS miner attaches when it adds nie:FileDataObject
information - it seems wrong for the tracks of a larger file to also
have type FileDataObject (necessary to set nie:url) but not have any
of the useful file-specific metadata that the FS miner would attach
(because we create the tracks as part of the preupdate).

It now seems more "correct" to me to make the tracks have no nie:url,
but relate them to the container file with nie:isStoredAs and add a
nmm:containerOffset propery which gives the time offset in the
container. Is this logical?

Sam