[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD
Date: Wed, 12 Dec 2018 13:06:36 +0100


now about the other aspects of Edd's mail from yesterday:

> How independent are my changes from yours after all?

I assume i take profit from your work in libcdio-paranoia.
Vice versa, my two changes should be beneficial on OpenBSD and NetBSD.
They fix non-fatal bugs.

My libcdio change is in gnu_linux.c. Not relevant for the BSDs.

So i need to submit to you:


Fix the display of tracks by cd-paranoia for the case that the CD
table-of-content begins by a track number higher than 1.

Symptom of the problem on OpenBSD with a CD that has tracks 7 to 11
is probably that no tracks are reported underneath the headline
  "Table of contents (audio tracks only):"

--- src/cd-paranoia.c.orig      2018-12-09 21:59:02.956749766 +0100
+++ src/cd-paranoia.c   2018-12-11 19:09:31.601363825 +0100
@@ -251,7 +251,8 @@ display_toc(cdrom_drive_t *d)
          "track        length               begin        copy pre ch\n"

-  for( i=1; i<=d->tracks; i++)
+  for( i=cdio_get_first_track_num(d->p_cdio);
+       i<=cdio_get_last_track_num(d->p_cdio); i++)
     if ( cdda_track_audiop(d,i) > 0 ) {

       lsn_t sec=cdda_track_firstsector(d,i);


Fix the automatic determination of drive audio endianness by cd-paranoia
for the case that the CD table-of-content begins by a track number higher
than 1.

Symptom on OpenBSD with track 7 to 11 is probably the message
  "Cannot determine CDROM drive endianness."
under the headline
  "Attempting to determine drive endianness from data......"

--- lib/cdda_interface/common_interface.c.orig  2018-12-09 21:57:17.716749368 
+++ lib/cdda_interface/common_interface.c       2018-12-11 18:56:01.209360765 
@@ -70,12 +70,13 @@ data_bigendianp(cdrom_drive_t *d)

   cdmessage(d,"\nAttempting to determine drive endianness from data...");
-  for(i=0,checked=0;i<d->tracks;i++){
+  for(i=cdio_get_first_track_num(d->p_cdio), checked=0;
+      i<=cdio_get_last_track_num(d->p_cdio); i++){
     float lsb_energy=0;
     float msb_energy=0;
-    if(cdda_track_audiop(d,i+1)==1){
-      long firstsector=cdda_track_firstsector(d,i+1);
-      long lastsector=cdda_track_lastsector(d,i+1);
+    if(cdda_track_audiop(d,i)==1){
+      long firstsector=cdda_track_firstsector(d,i);
+      long lastsector=cdda_track_lastsector(d,i);
       int zeroflag=-1;
       long beginsec=0;


It might be easier for you to just take them from this mail rather than
teaching me how to submit them to your git.

I deem them not copyright-worthy and sign them off in the sense that
they are made solely by me and impose no problem for the overall GPLv3
of libcdio-paranoia.

> I'm versed with pull requests, but not with GNU practices.

There are not much GNU practices. GNU maintainers are a very loose group.
I am interested in libcdio because it is technical related to my own
knowledge as developer of libburn, libisofs, libisoburn, and as maintainer
of GNU xorriso.

Rocky Bernstein wrote:
> > FSF copyright release form

Edd Barrett wrote:
> Let me know about this. As long as I don't have to sign my soul away.

My most recent info about possible FSF copyright claims is in

It quotes a mail that i got directly
  From: Donald Robertson <address@hidden>
  Date: Mon, 7 Nov 2016 10:44:24 -0500
  Message-ID: <address@hidden>

My reaction was to offer my potential copyrights within libcdio to Rocky
If he deems it necessary to name me as copyright holder, then i am ok
with GPLv3+ (or with LGPLv2+ or 2-clause BSD license).

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]