-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesus Climent wrote:
> On Fri, Jul 07, 2006 at 02:45:14PM -0500, Charles Steinkuehler wrote:
>>
>> abcde.leadin.patch is a simple patch to pass cdparanoia the range '0-'
>> instead of '$FIRSTTRACK-$LASTTRACK' when doing a onetrack do_cdread,
>> which causes any lead-in to be ripped along with the audio tracks.
>
> The problem with this patch is that it breaks the possible option of ripping a
> CD with both a leading track and an end track, which right now is allowed. I
> will have to add a way to check that no track range has been passed in the
> command line and use that as a signaling to rip "0-" in cdparanoia.
In addition, I have found passing cdparanoia a start track of zero fails
on disks that do *NOT* have lead-in data before track one (ie: track one
starts at LBA=150/MSF=00:00:00).
There will have to be some code that translates FIRSTTRACK from 1 to 0
if the first track start position is > 150 and it is desired to rip the
lead-in.
No patch for this yet, although switching from a hard-coded track range
of 0- to [00:00:00.00]- seems to work regardless of the track-one start
position.
BTW: I'm fairly handy with shell scripting (having worked with LRP/LEAF
for many years), and will probably be adding code to do the track 1 > 0
translation in the near term. Are there any coding standards you're
trying to follow? There are a lot of handy bash features that aren't
being used in abcde (arrays, ${var/x/y} substitutions, etc), but this
may be for portability. Please let me know if there are any specific
bash-isms to avoid using...most of my scripting for LRP/LEAF was done in
ash, so I know all about scripting without the fancy bash enhancements
when I have to! :)
QUESTION: It looks like there is a desire to support a one-track rip
with user-specified track ranges. I would like to add support for
ripping the *ENTIRE* disk (including lead-in, if any) to a single file.
To merge these requirements, I expect something will have to be added to
the abcde configuration file or command line arguments. Two things that
have come to mind:
1) Add a "LEADIN" variable to abcde.conf. If set to Y/Yes, anytime
track one is being ripped any lead-in data is ripped along with it.
2) Add a "Whole-disk" command-line switch (or special case to the
track-range specification logic), which tells abcde to rip the lead-in
along with all audio tracks on the disk.
Is there a preference for one of these methods over the other, or some
other solution? I'd probably lean towards the second solution, adding
some track-range specifier (all, -, or something) to the track-range
logic, as this seems less intrusive to the rest of abcde's operation.
In either case, the cue file will have to be mangled to reflect the
user-specified range unless the entire disk (including lead-in) was ripped.
- --
Charles Steinkuehler
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFEtRBIenk4xp+mH40RAn4fAJ9A9RU6y9r3oTF1yG4jgf3g5kSaEgCfXyEW
YV0lN4wDZ1I/UD2/ydE7vso=
=otTp
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
