A Good Program To Rip Music Cds And Encode

[shanenin]

pythonrip.py

I wrote a fairly useful program for ripping and encoding your music cds to mp3. The cool thing it does is uses the CDDB data base to get the real names of the songs, so it can name them properly. It also makes the song titles linux friendly by replacing spaces with underscores. It is really easy to use. you just make a directory, change into the directory, and run the script. It will prompt you for the desired bitrate to use. If you deside to try it, let me know how it works for you.

it has one known issue. the CDDB module seems to need read access to your cdrom(at least on my computer). You can either run the script as root. Or a better idea is to do this command as root, then run the script as regular user

chmod +r /dev/hd*

this above code assumes you have an ide cd drive

It depends on the following

python

CDDB.py

cdparanoia

toolame

Edited August 10, 2005 by shanenin

[iccaros]

looks good to me. the only change is that most Linux distros see /dev/cdroms/cdrom is a link to /dev/hd? for the cdrom. so its more standard to use /dev/cdroms/cdrom or /dev/cdroms/cdrom0 as 2.6 kernel will put them in /dev/ that way (its a hard link so you can still chmod it. )

[shanenin]

I originally tried chmoding /dev/cdrom, but since that is just a a soft link, it made no difference. I did not realize /dev/cdroms/cdrom is a hard link.

So your are sayung more linux computers will have /dev/cdroms/cdrom* then /dev/hd* ?

how can you tell a hard link from a soft link, ls -l does not see tho show any difference ?

I would really like to figure out a universal way to change /etc/udev/rules.d/* file so the installer I am going to make could give the user the option to make the chnages to permissions of /dev/hd* permanent.

[jcl]

how can you tell a hard link from a soft link, ls -l does not see tho show any difference ?

Symlinks have an 'l' in the first field of the permissions line. Everything else (more or less) is a hard link.

I would really like to figure out a universal way to change /etc/udev/rules.d/* file so the installer I am going to make could give the user the option to make the chnages to permissions of /dev/hd* permanent.

<{POST_SNAPBACK}>

Neither udev nor /dev/hd* are universal.

There isn't really any way to correctly identify the device node for the CD-ROM without user invention.

Edited August 10, 2005 by jcl

[shanenin]

Neither udev nor /dev/hd* are universal.

don't almost all new distros use udev, and /dev/hd* to reperesent ide drives? I would be happy if the script worked for 80- 90 % of people. It would be a nice start.

[jcl]

Neither udev nor /dev/hd* are universal.

don't almost all new distros use udev, and /dev/hd* to reperesent ide drives? I would be happy if the script worked for 80- 90 % of people. It would be a nice start.

<{POST_SNAPBACK}>

I have no idea about how many distros ship with udev or what fraction of the market they represent, but I wouldn't be surprised if it was less than 80%.

As far as hd?, AFAIK every distro does indeed use hd? for IDE devices. However, there are machines with SCSI, USB, and Firewire CD drives, multiple drives, drives that connected intermittently, and so on. You would probaly be fine in the middle of the hardware range -- low-end workstations, desktops, and high-end laptops -- but as you get closer to very large (high-end workstations and desktops) or very small (ultraportables) it becomes less and less likely that it will work.

/dev/cdroms should take care of the device type issue but off the top of my head I can't think a way to deal with multiple drives or drives that don't exist at install time. The most automated may to do it, I think, would be to have the install script guess and give the user the opportunity to correct the guess.

[iccaros]

it might be better to grep /etc/fstab for cdrom and ask if it does not find it.

you may need a setup program that writes a config to a file, this way they could also just edit the file if they don't what to run the setup app.

Im working on a WxPy front end so that people can also have a GUI and it will also work windows, MAC and Linux (Unix, Solaris,BSD,IRIX ect.)

[shanenin]

/dev/cdroms should take care of the device type issue

it might be better to grep /etc/fstab for cdrom

even if I know what the device is, chmoding only works until the user reboots. I need to make this permanent. I need to find a way to automatically config the udev config file.

here is what my ubuntu config looks like, this might be easy to change. although I have not tested it yet. Maybe I can just change mode to MODE="0664" I suppose I could reboot and try it

# permissions for IDE CD devices
BUS="ide", KERNEL="hd[a-z]", SYSFS{removable}="1", PROGRAM="/bin/cat /proc/ide/%k/media", RESULT="cdrom*", NAME="%k", MODE="0660", GROUP="cdrom"

on my gentoo system I have tried messing around with udev rules , but have had no luck makeing my ide devices boot with the mode 664.

edit added later//

I just changed that config file and booted ubuntu, I saw my drive being regonized when the kernel first got loaded. When I did ls -l /hd* I had no /dev/hdc*. My drive was unresponsive, it would not even open with the button. I changed the file back to the original config and still nothing(after a reboot). I booted gentoo, and the drive works fine.

Edited August 11, 2005 by shanenin

[jcl]

Heh. I try to stay as far away from the udev config files as possible. If I have problem, I just wait until it fixes itself.

You might want to make sure the needed modules are loaded. I had /dev/hdc* vanish last week and fixed it by modprobe'ing the cdrom module.

Edited August 11, 2005 by jcl

[shanenin]

thanks I will have to try that(modprobing)

isn't messing with my udev config the only way I will be able to permanetly change permissions of device files?

Edited August 11, 2005 by shanenin

[jcl]

isn't messing with my udev config the only way I will be able to permanetly change permissions of device files?

<{POST_SNAPBACK}>

Yeah. Good luck.

[shanenin]

maybe using sed in a script to start changeing /etc/udev/* of users of my program is not a good idea. I would have warned them before letting the script procede to kill ther linux system :-)

A better solution would be to figure out why the CDDB.py module needs read access to the cdrom. I wonder if it could be changed. Many of the other non python ripper programs that use the CDDB don't need to run as root. They must be using a clib of some sort.

Edited August 11, 2005 by shanenin

[jcl]

A better solution would be to figure out why the CDDB.py module needs read access to the cdrom. I wonder if it could be changed. Many of the other non python ripper programs that use the CDDB don't need to run as root. They must be using a clib of some sort.

<{POST_SNAPBACK}>

It needs to be able scan the CD's table of contents in order to identify the disc.

Incidentally, Gentoo apparently gives read permissions for CD-ROM to everyone in the cdrom group. No need for root. Other distros may do the same.

Edited August 11, 2005 by jcl

[shanenin]

shane@mainbox shane $ cat /etc/group | grep cdrom
cdrom:!:19:shane

I seem to be in the cdrom group, but it is still not letting me read the disk as user. what does " ! " do. It seems out of place?

Also the part of the python module that fails as regular user is the module DiscID.py(CDDB.py uses DiscID).

[jcl]

shane@mainbox shane $ cat /etc/group | grep cdrom
cdrom:!:19:shane

I seem to be in the cdrom group, but it is still not letting me read the disk as user. what does " ! " do. It seems out of place?

No idea. The manpage says that's the password field. Google suggests that it's a legacy feature and not widely used. I have 'x' in the password field for every group. [Edit: Looks like it's used with newgrp and sg. Which is to say, not often.]

Also the part of the python module that fails as regular user is the module DiscID.py(CDDB.py uses DiscID).

<{POST_SNAPBACK}>

Sounds right. It iterates over the entries in the disc's TOC and generates a checksum that's used to ID the disc.

Edited August 11, 2005 by jcl

[shanenin]

I found this solution. create this file to add any special permissions you want

/etc/udev/permissions.d/00-myrules.permissions

then just add the following lines

hdc:root:users:664

hdd:root:users:664

this should cover virtually everyone using udev. In all honesty I think the reason I need to do this is my permissions are not set up properly.

Edited August 11, 2005 by shanenin

[iccaros]

in the fstab if you add users then users could mount and read. I'll pull my fstab k3b made for it.

I found this solution. create this file to add any special permissions you want

/etc/udev/permissions.d/00-myrules.permissions

then just add the following lines

hdc:root:users:664

hdd:root:users:664

this should cover virtually everyone using udev. In all honesty I think the reason I need to do this is my permissions are not set up properly.

<{POST_SNAPBACK}>

[shanenin]

are you sure? I think read access is only for mounted stuff. Since my drive is not being mounted, I don't think /etc/fstab would affect it.

[iccaros]

no, I know it will allow users to mount the drive which, mine is chmod 4711

from the chmod man page

4000 (the setuid bit). Executable files with this bit set will

run with effective uid set to the uid of the file owner.

Directories with this bit set will force all files and sub-

directories created in them to be owned by the directory

owner and not by the uid of the creating process, if the

underlying file system supports this feature: see chmod(2)

and the suiddir option to mount(8).

k3b runs a config script that looks for /dev/cdroms/

and chmods the files under it. it may also run cdrecord to see what is a cd writer or not. but that part is not important.

if you made a a quick bash config script that greped /etc/fstab for cdrom and then cmod the mount you should be good to go.

this must be ran as root but that is simple to ask for. or jcl has a bash starter that will make a script run as root or ask for root password when ran.

Edited August 12, 2005 by iccaros

[shanenin]

If I am reading that correctly, that still is refering to a mounted file system. When reading an audio disc, it is not being mounted. I can even remove all lines from my fstab file about the cdrom and it will still read fine. the forth field in the fstab file are options for a mounted file system. which my cdrom is not being mounted to be used.

[jcl]

In all honesty I think the reason I need to do this is my permissions are not set up properly.

<{POST_SNAPBACK}>

Odd. It looks like you're in good shape. Just being in the group works fine for me.

~ $ grep cdrom /etc/group
cdrom:!:19:jcl
~ $ ll /dev/hdc
brw-rw----  1 root cdrom 22, 0 Jul 30 21:06 /dev/hdc
~ $ dd if=/dev/hdc of=c count=512
512+0 records in
512+0 records out
~ $ file c
c: ISO 9660 CD-ROM filesystem data 'Maemo Live                     ' (bootable)

[iccaros]

If I am reading that correctly, that still is refering to a mounted file system. When reading an audio disc, it is not being mounted. I can even remove all lines from my fstab file about the cdrom and it will still read fine. the forth field in the fstab file are options for a mounted file system. which my cdrom is not being mounted to be used.

<{POST_SNAPBACK}>

sorry forgot to hit submit on my edit.. it may make more sence now what I am tring to say,

chmoding the mount (not in your fstab) will make all action on it act like root is doing it. I suggested the fstab for finding a persons mount (not mount point)

Edited August 12, 2005 by iccaros

[shanenin]

shane@mainbox shane $ dd if=/dev/hdc of=c count=512
dd: opening `/dev/hdc': Permission denied

Hmm.

[iccaros]

ok a little experiment...

I did

bash-2.05b$ dd if=/dev/hda of=/tmp/cd.iso count=512
dd: opening `/dev/hda': Permission denied
bash-2.05b$ id
uid=1000(huskeyw) gid=100(users) groups=10(wheel),19(cdrom),35(games),100(users)

same error you have, but them I changed to /dev/cdroms/cdrom0

bash-2.05b$ id
uid=1000(huskeyw) gid=100(users) groups=10(wheel),19(cdrom),35(games),100(users)
bash-2.05b$ dd if=/dev/cdroms/cdrom0 of=/tmp/cd.iso count=512
512+0 records in
512+0 records out
bash-2.05b$

[iccaros]

never mind .. I see I tested hda not hdc...

here is my hdc

bash-2.05b$ dd if=/dev/hdc of=/tmp/cd.iso count=512

512+0 records in

512+0 records out

which kernel are you running. I remember that 2.6.9 - 2.6.10 (I think ) restricted access to cdrom to root at least for writing.

huskeyw root # uname -a

Linux huskeyw 2.6.11-gentoo-r6 #2 SMP Sat Jul 30 09:39:57 EDT 2005 i686 Intel® Pentium® M processor 1.80GHz GenuineIntel GNU/Linux

huskeyw root #