Provide command-line switch for choosing the drive

[themaddoctor]

Once in a while I could use a "-d" switch to choose the drive.

If I overcome my laziness, I might try to implement it myself. We'll see.

[arcctgx]

That's another thing I considered but thought unnecessary. After all, most modern PCs don't even have an optical drive anymore. And suddenly a person who has more than one CD drive in their machine appears. :wink:

At this time implementing this feature is more complex than it should be. This is because the logic of command-line parsing assumes there either is a CD in the default drive, or that the MusicBrainz disc ID is used instead of physical medium. Other possibilities are not expected. But it should be much easier after parsing code is refactored to implement #1.

How do pycdio and discid behave when there is more than one CD drive? Is the behavior consistent, or do they try to use different CD drives at random and the behavior is different in each runtime?

[themaddoctor]

I looked a the code for discid, and it has an optional parameter for the device. E.g.:

print(discid.read("/dev/cd1").toc_string) 1 13 222350 150 18802 36280 50055 66910 84157 101770 117815 135207 153755 170105 188655

Without that parameter, it uses the default device, whatever that is, and however that is set.

[arcctgx]

That saves me some checking, thanks. How about pycdio, does it also accept strings like /dev/xyz as device specification?

[themaddoctor]

pycdio.close_tray("/dev/cd1") works as expected.

TypeError: in method 'get_track_lba', argument 1 of type 'CdIo_t const *' too complicated; brain hurts.

[themaddoctor]

So far, ARver has always used the expected default device. So that answers your question about consistency.

[arcctgx]

I'm more less done with this enhancement, but I can't fully test it myself because I only have one CD drive in my machine. So I will need your help with testing.

Do you want me to make a development release you could install using pip?

[themaddoctor]

This is very kind of you to do. If you think that everything should be done at this point, make a dev release. Otherwise, just end me a patch. I'm working on the Led Zeppelin discography at the moment, so there are plenty of opportunities for testing. Thank you.

[arcctgx]

I think a dev release is appropriate now. That's what they're for.

• https://github.com/arcctgx/ARver/releases/tag/v1.4.0.dev2
• https://pypi.org/project/ARver/1.4.0.dev2/

Add --pre option to pip install, otherwise it won't install a pre-release. Sorry if I'm stating the obvious, but I only learned this just now. :wink:

[themaddoctor]

OK, first test is successful. I tried a disk with no pregap and no data track. All of these behaved as expected:

With disk in default drive: arver .wav OK With disk in default drive: arver -d /dev/cd0 .wav OK With disk in default drive: arver -d /dev/cd1 .wav EXPECTED ERROR With disk in second drive: arver -d /dev/cd1 .wav OK arver -t .wav OK arver -t -P 0 -D 0 .wav OK arver -i wNJosT4Ejg_2oIf60Uxf6ymaJmw- *.wav OK

[arcctgx]

I'm working on the Led Zeppelin discography

arver -i wNJosT4Ejg_2oIf60Uxf6ymaJmw- *.wav

Checks out. :wink:

Thanks for testing. Take your time, I'm not in a hurry to release v1.4.0. There's still something I want to add before the next stable version.

[themaddoctor]

I haven't come across an enhanced CD in a while. When I do, how do I calculate the input for -D? ceiling(length(data.iso)/588/4)?

[arcctgx]

Assuming you got the data length in bytes, then it's X bytes divided by 2352 bytes per CD audio frame, rounded up to the next integer value. But I'm not sure how you're getting this length, so you have to make sure it's accurate (e.g. if it does not include the 11400 frames gap between the last audio track and the data track).

But I think that implies you have a CD, so why use -D at all? (if not just for testing)? And if you're just testing, arver-discinfo will read the TOC directly and tell you how long the data track is.

In any case, calculating AccurateRip disc ID based on file lengths, pregap and data track length is quite well tested with unit tests, so I wouldn't focus on that too much.

[themaddoctor]

FYI: The header of an ISO filesystem contains an entry telling you how many 2048-byte blocks are in it. There is a tool, isoinfo, that can read that. I think that "isoinfo -d -i /dev/cdrom" will find the data track and read its header.