[Libburn] Reading procedure

[Derek Foreman]

On Fri, 22 Oct 2004, Tiago Cogumbreiro wrote:

> On Wed, 2004-10-20 at 02:51, Derek Foreman wrote:
>> On Fri, 15 Oct 2004, Tiago Cogumbreiro wrote:
>>
>>> Hi list,
>>>
>>> I've been thinking about how the reading procedure should be visible to
>>> the user.
>>>
>>> Derek told me the source will be an abstraction layer. One of the
>>> sources will be the real cd drive, the others I assume are cd images, is
>>> this it?
>>
>> I'm sorry, I was unclear.  The abstraction defines where the data will be
>> put after it is read from a cd.
>>
>>> My proposition is that optical media, aka CD's, DVD's and all, should be
>>> presented to the user as an array of data streams, a stream is like C's
>>> FILE struct. It is an array because there are multitracked optical media
>>> and the user needs to destinguish them, for example when extracting
>>> audio tracks from a CD. But we also want to enhance the library with the
>>> possibility for the user to implement it's own error recovery
>>> technology, while reading the streams, this is the simple Strategy
>>> pattern[1].
>>
>> Interesting.  This isn't quite how I'd planned to expose the CD to a
>> regular app.
>>
>>> Let's call the strategy the 'data filter' (DF). What is the DF? It's
>>> basically a hook function that we need to send a certain number of
>>> arguments in order to provide a way to let the user correct the read
>>> errors.
>>>
>>> Most of you might not know, but my interest on libburn began because I
>>> had my own cdrecording library[2] and thought it was a duplicate effort
>>> to work on it when there was already libburn (which is more advanced).
>>>
>>>
>>>
>>> 1. The filter
>>>
>>> In that project I implemented what I am talking about, and the handler
>>> was designed as [3]:
>>> /* translated to C, since it was made in Java
>>> * @source - the data source
>>> * @read - the structure responsible by reading the data from the
>>> optical media
>>> * @sector - the sector you want to read from the CD
>>> * @ret_buff - the returned buffer
>>> * @ret_buff_len - the size of the returned buffer
>>> */
>>> int read_frame (burn_read_source *source, read_operation *read, int
>>> sector, char **ret_buff, int *ret_buff_len);
>>>
>>> This type of callbacks assumes there is someone controlling which lba to
>>> read next. Is this what we want? Is this enough flexibility for what we
>>> need? This will open on the API a function for getting the data from a
>>> given sector, which is READ_CD (0xBE).
>>>
>>> 2. The manager
>>>
>>> Another way to make it extendable would be to let the user define how to
>>> divide the media in streams. For example, an audio source being treated
>>> as a single stream, or each session being represented as a stream, or
>>> the user data being represented as a stream and the subs as another. In
>>> this case the hook function would have to define how the data is
>>> represented. This will still need the READ_CD op as public. And is
>>> somewhat compatible with the extendability explained beforehand.
>>>
>>> 3. Usage
>>>
>>> The usage would be something like this.
>>>
>>> BurnReadSource *source;
>>> source = burn_read_source_new (burn_read_media_new(),
>>> burn_read_manager_new(), burn_read_filter_new());
>>> BurnStream *streams[];
>>> int i, streams_len, buff_len;
>>> char buff[1024];
>>>
>>> burn_read_get_streams (source, &streams, &streams_len);
>>>
>>> for (i = 0; i < streams_len; i++)
>>> 	for (buff_len = burn_stream_read (streams[i], buff, 1024); buff_len >
>>> 0; buff_len = burn_stream_read (streams[i], buff, 1024))
>>> 		write (out, buff, 1024);
>>>
>>> What are your impressions on this?
>>
>> I'd only really thought about the interface at the highest level...
>>
>> You register a "burn_sink" with the lib.  The "file sink" would be
>> provided by libburn, the same way a file source is now.  More advanced
>> sinks would have to be written by the developer.
>>
>> A burn_sink would define a target for data.  libburn itself would read
>> sectors from the disc, and pass the data to the burn_sink callback
>> function.
>>
>> The libburn read functions would operate on the disc/session/track
>> structures only after a sink has been registered.
>>
>> So to read a track, you'd do something like
>>
>> sink = burn_file_sink_new("filename.img", "filename.sub");
>> disc = burn_drive_get_disc(whatever);
>> burn_read_disc(drive, disc, sink);
>>
>> And libburn would dump the disc to a file.
>>
>> A more advanced data sink would be able to feed sectors into something
>> like gstreamer for on the fly mp3 encoding, use C2 error information to
>> discard "corrupt" sound, or read sections of the disc backwards to find
>> "hidden" data.
>>
>> A basic app probably shouldn't have to deal with sectors at all, and
>> should stay in the realm of discs, sessions, and tracks.
>>
>> I'm thinking what you propose should go in the mid layer, and be how sinks
>> operate internally.  They'll pull from the drive in sectors, and push to
>> the app through callbacks.
> Yes, my proposition is in a lower level. So my first question is where
> should I start hacking on?

Well, the read commands are already there, and I think they're general 
enough that they need no change.  (correct me if I prove to be wrong 
though :)

also, if you want it, I think the old archaic read code also has the 
functionality to skip certain parts of the disc that are guaranteed to 
have no user addressable data (pre and post gaps).  In fact, it might be 
possible to salvage quite a bit of that code if you're interested.  But 
I'm not attached to it if you're not.

For debugging purposes, it would probably be easiest to hack up a fairly 
simple interface that just rips a disc/track/session to a file, and then 
add the "sink" crap to it later.  (or make me write the sink 
infrastructure)

Wanna do that?  I'd merge something like that into cvs head with a big 
warning that the API is going to change.

> I've just bought a new DVD+-rw with dual layer support, I imagine this
> feature is transparent to the user (libburn) and only alters the media
> size. Bottom line is: I am interested in playing around with dvd burning
> as well.

I haven't played with dvd structure generation at all, or commands to send 
the structure info.  That should all be in the mmc docs though.

> Maybe you could add one more link to the libburn webpage:
> Linux udf project has a set of tools (udftools) which mess around with
> drives too (for formating them, sending packets...)
> http://cvs.sourceforge.net/viewcvs.py/linux-udf/
>

Ok