libcdio-devel
[Top][All Lists]
Advanced

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

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


From: Edd Barrett
Subject: Re: [Libcdio-devel] CD_MSF_FORMAT vs LBA on NetBSD
Date: Sat, 15 Dec 2018 19:20:09 +0000
User-agent: Mutt/1.11.1 (2018-12-01)

Evening everyone,

On Wed, Dec 12, 2018 at 02:25:54PM -0500, Rocky Bernstein wrote:
> One wonderful thing about git is that it's very hard to *totally* mess up
> the history. And because git repositories are disributed in the same way
> that blockchains work, there are multiple copies with that have essentially
> all of the history. In fact, I have three of them myself on different
> computers.

And also `git reflog` unlocks the undo of all undos! 

Now for Thomas' proposed changes:

> 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):"

Correct. Before it shows no tracks, now it shows correct track listing.

> 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......"

Again, correct! And now I have:

---8<---
Attempting to determine drive endianness from data.......
        Data appears to be coming back Little Endian.
        certainty: 100%
--->8---

I've sucked Thomas' changes into my cdio-paranoia branch, done a bit of
squashing and rebasing, and tidied up my commit messages.

I tested the whole lot on NetBSD. All looks well apart from one minor quirk. In
the output of cd-info we have an ioctl error:

---8<---
...
 11: 09:41:34  043459 audio  false  no    0        no
170: 12:48:10  057460 leadout (128 MB raw, 128 MB formatted)
Media Catalog Number (MCN): not available
Last CD Session LSN: ++ WARN: ioctl CDIOREADMSADDR failed: Invalid argument

failed
audio status: no status
volume level port 0: 255 (0..255) 100 (0..100)
...
--->8---

But it carries on OK regardless.

And similarly in `cdparanoia -Qv`:

---8<---
...
Checking /dev/rcd0d for cdrom...
                CDROM sensed: TEAC     DW-224E-C        1.8B

        Setting read block size at 8 sectors (18816 bytes).
++ WARN: ioctl CDIOREADMSADDR failed: Invalid argument
...
--->8---

And similarly in `cdparanoia -B`:

---8<---
...
(C) 2014 Robert Kausch <address@hidden>

Report bugs to address@hidden

++ WARN: ioctl CDIOREADMSADDR failed: Invalid argument

405: Option not supported by drive
Ripping from sector       0 (track  7 [0:00.00])
...
--->8---

I'm happy to test any proposed fixes for that, but I don't want it to block the
OpenBSD fixes, especially since it isn't fatal. 

(We know we can ignore the 405 message, the drive speed ioctl)

So I have two candidate branches for merge:

 * https://github.com/vext01/libcdio/commits/openbsd_fixes_to_master_for_merge
 * https://github.com/vext01/libcdio-paranoia/commits/start-track-num-not-one

Do you guys want to check them before we do the merges?

-- 
Best Regards
Edd Barrett

http://www.theunixzoo.co.uk



reply via email to

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