Re: [Libcdio-devel] Re: mmc_get_disc_erasable proposition + questions

[Rocky Bernstein]

I think the best first step is just to try to isolate the MMC part and worry
about other issues later.

Given the history and assumptions that were made when libcdio (or rather
vcdimager from which libcdio was derived), I don't belive that it is as
fruitful to try to extend that as start again from scratch understanding the
current situation.

CD's have at most 100 tracks and they have a media size limit which nowadays
may seem small. But given this, it made sense to statically allocate space
for track information for the at-most 100 tracks. Furthermore, the size of
an track index can fits nicely in one byte. And the number of bytes in a CD
can fit into a 32-bit number. For CD's, track number 0xAA is designated the
leadout track which is okay since again the largest valid track number is
100. The fact that the standards said up front that these were the limits
and that's what the leadout track number has to be, gave confidence to those
limit-assuming design decisions which are now baked into code.

I think OS implementations, like vcdimager/libcdio, many times also based
their implementation on such strict limits; that's why their CD-orientated
structures they are not amenable to non-CD oriented media.

In a world where this is no longer true, one probably wants to implement
things differently.  So in sum, I don't think it is a simple matter of
"strict" versus non-strict. Or just simply extending.

That said, in this other optical media library one may want put in
"strictness" checks that aren't an issue for things like libcdio because
they just can't be violated. But adding such checks of course will make the
optical media library implementation more complex.

Sure, I agree that for the average Joe there is a lot to be done to make
things simple. That Thomas and Frank (and folks who have used the libcdio
CDDA stuff in media players) have been able to use libcdio without too much
trouble or additional code in their application (and certainly little
involvement on my part) is encouraging.  Are things ideal? Well with respect
to non-CD media, I think the answer is obvious.

But I also believe a lot of the complexity has to do with the nature of
what's going on. Specifically one aspect is that hardware OEMs have
ever-changing and competing new features; also medium capabilities varies.
OEM's are not focused on software design or simplicity. The standards group
focus is more at the hardware interface than the software interface side.

So who represents the programmer? Well now and then various companies which
sell OS's (i.e. Microsoft and Apple) will have to do so. But they both come
at it assuming that programmers will only use their OS. For Open-source OSs
like FreeBSD and GNU/Linux, it is up to random unpaid individuals doing this
as a hobby.

In general I think there will be progress. Given that libcdio is 8 years old
and the MMC work 6 years and only now is there interest in making it better,
I think that is some indication of how fast things progress.


On Sat, Feb 6, 2010 at 1:24 PM, Mario Đanić <address@hidden> wrote:

> Hello,
>
> please find my comments inlined.
>
> On Sat, Feb 6, 2010 at 18:49, Rocky Bernstein <address@hidden> wrote:
> > On Sat, Feb 6, 2010 at 12:15 PM, Mario Đanić <address@hidden>
> wrote:
> >
> >> > And at the same time, where folks want strict compliance for any given
> >> > standard they can get that too by using the specific library desired.
> >> >
> >>
> >> Sigh, that sounds like a bunch of libraries.
> >
> >
> > I don't see that the *number* part is a problem. Right now on my ubuntu
> > computer in /usr/lib  I have 351 shared libraries (.so's).  And if I do a
> > "ldd xine" I come up with 41. If the numbers were 355 or 45 that wouldn't
> > bother me at all.
> >
>
> As a random user, I don't bother about number of libraries either. But
> when I have to develop things, I need to choose what to use - more
> choices often lead to more confusion.
> Education and documentation helps, but this problem is not trivial,
> and we can't dismiss it off-hand as non-important.
>
> > Applications only need to use those libraries that are desired. The
> author
> > of the application is in a better position that me or libcdio to know how
> > much generality and compliance is desired.
>
> I agree, the author of the application is in the best position to do that.
>
> >
> > It sounds like you wants to create a single all-encompasing library that
> has
> > might have loose compliance with anything but is very practical and can
> do
> > everything folks are likely to want to do in optical media, then that's
> the
> > one library your burning application might access.
>
> I want us to make burning a pleasant experience. So far a lot of the
> people I've had the privilege to talk to had numerous problems. Some
> are related to GUIs, some to underlaying technology, etc, etc ... but
> the thing is - we don't yet provide a consistent and nice experience
> for the average, or not so average Joe.
> >
> > On the other hand, suppose you are doing something strictly of a CD
> nature
> > and say only care about Red-Book CDs. Then although one could use the
> > everything hybrid library, I think I would tend to use the libcdio
> library.
> > If nothing else it would be stricter about ensuring that you come up with
> a
> > valid CD because that's all it *could* do.
> >
>
> How about designing the api so it would have a "strict" mode? Please,
> do not think that I am against several libraries. If there is a valid
> reason for creating a new library from scratch, or by stripping-out
> parts of code from anything existing (like libburn or libcdio) I am
> all for it.
>
> >
> > From my position, optical
> >> media recording scene is fragmented enough as-is, and one of the
> >> reasons behind Libburnia project is to unify efforts on "burning"
> >> matters on Linux, and then possibly other platforms.
> >>
> >
> > So again, I think what you want is this hybrid loose compliance library
> for
> > burning. And the best way to make sure it happens is to "vote with your
> > feet" or do it.
>
> I can only hope I've helped that cause at least a bit with the
> libburnia project.
>
> >
> > So I'm just suggesting doing this separate from libcdio *library* which
> was
> > intended for CDs.  (It is open for discussion as to whether you want to
> do
> > this inside the libcdio *project* or outside. If there are internal parts
> of
> > libcdio that should be moved outside to help things along, that's okay.
> > We've discussed for example moving MMC outside by turning it into a
> library
> > which libcdio and perhaps libburnia use)
> >
>
> I have no problem with moving MMC parts outside both libburnia
> libraries and libcdio. In fact, I might have something to offer on
> that ground as a starting point for discussion.
>
> > Personally I think doing this makes things much cleaner and easier to
> work
> > on. There is no backward compatibility to worry about. Furthermore one
> can
> > reassess any of the assumptions made in a more fundamental and radical
> way.
>
> Cleaner, and easier to work with? ++ on that one.
>
> >> I will try to get up to speed as soon as my laptop is back, and in the
> >> mean time I'll read your discussions as I can.
> >>
> >
> > I look forward to your thoughts and views. Thanks in advance for any help
> > you can give.
> >
> > Quite frankly I do not consider myself an expert any of the things
> libcdio
> > purports to understand. As I wrote in the history section of libcdio
> > documentation, this started as my own personal and individual discomfort
> > with DMCA.
> >
> I will try to help as much as I can. While I'm most certainly not an
> expert, I've picked up a thing or two, and have a lot of experience
> about how users perceive optical media recording gathered from the
> conferences where I spoke about burning and from maintaining
> Gnomebaker.
>
> Cheers,
> Mario
>
>
>