similar to: [Flac-users] > Re: Compression of single-file CD image

I just finished up a port of Andy Polyakov's excellent dvd+rw-tools to FreeBSD, and he has incorporated the patches into his release: http://fy.chalmers.se/~appro/ http://fy.chalmers.se/~appro/linux/DVD+RW/ http://fy.chalmers.se/~appro/linux/DVD+RW/tools/ (version 5.8.4.4.4) These tools support DVD-R, DVD-RW, DVD+R, and DVD+RW format dvd burners, including the popular Sony

Hi, This also has been discussed in SSHSCI's SSH context. All SSH versions (both SSHSCI and OpenSSH) derive value for DISPLAY variable from `uname -n`. The problem is that the returned value is not necessarily resolvable to a valid IP number which in turn might cause a failure. To make it fool-proof I suggest to set DISPLAY to the interface's address the user has reached the system in

Hi, I've already discussed this issue in SSHSCI's SSH 2.2 context on ssh at clinet.fi list. My standpoint is that it's wrong and meaningless to perform chown in sftp-server as the file is most likely copied between systems with distinct accounting system where user is not necessarily (and even unlikely) has same numeric user id. The original bug report was that user couldn't

I'm not subscribed to this list; but I read that Matthew Dillon has ported the dvd+rw tools to FreeBSD. I just compiled and installed the application; but I can't burn to a DVD+RW on a Sony DRU-500A. command: growisofs -Z /dev/acd0c -rl ./testfile result: ":-( unable to CAMGETPASSTHRU for /dev/acd0c: Inappropriate ioctl for device" The DVD+RW website:

Hi, I am running Centos 4 (fully updated on this box). I removed the old DVD writer (/dev/hdc) and installed a new LG GH20 "Internal Super Multi DVD Rewriter" with a SATA interface - this shows up as /dev/scd0. When I insert a pre-recorded DVD autorun mounts it and displays the contents without any hassles. It appears to me that the required kernel modules are loaded - as copied

appro@fy.chalmers.se wrote: > > No, it's not:-) > > static int sig_pipe(void) > { > BlockSignals( True, SIGPIPE ); > > DEBUG( 0, ("Got SIGPIPE\n") ); > if ( !is_daemon ) > exit(1); > BlockSignals( False, SIGPIPE ); > #ifndef DONT_REINSTALL_SIG >

That's where I first went for information. I've successfully burned a CD-R using cdrecord, as opposed to burncd, which I would normally use for ide burners. I will check on the firmware. Thanks, Andrew Gould --- "Thomas T. Veldhouse" <veldy@veldy.net> wrote: > Try visiting > http://fy.chalmers.se/~appro/linux/DVD+RW/ and make > sure your > hardware is

Hi, We're planning to deploy PXELINUX as a primary kernel loader in cluster environment. Problem is that we plan to have IP numbers assigned dynamically while there is no guarantee that all machines has same CPU architecture. This makes IP-based config search algorithm inappropriate for our purposes because we [naturally] expect loaded kernel to match hardware. For this reason I've

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

Hi there. First of all, I'd like to congratulate to developers for making a free specification and LGPLed decoder/encoder. :-). I did some test, ripping 17 tracks of my CD and converting them to both MP3 and OGG format. MP3 encoder/player was Lame 3.70 OGG encoder/player was from a Saturday nightly tgz package. ------------------------------------ MP3: LAME-3.70 mpg123-0.59r-4 MP3: lame -S

--- Curt Sampson <cjs@cynic.net> wrote: ... > Next, I rip the entire CD using cdrdao. This generates a .bin file > containing the raw audio data and a .toc file containing the table of > contents of the CD. There's still a problem here: I don't have the > subcode data (from channels R through W). There's a possiblity that > cdrdao will keep CD-Text data, since the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Edwards wrote: > Hi, > > Bit late to join in the discussion but I've just read through the CD > archiving discussion and was particular interested in Dax's method, > described here (also included below): > > http://lists.xiph.org/pipermail/flac/2006-September/000611.html > > So far I've just been

I realize this was an answer to someone else, but... I use Trader's Little Helper for all my encoding/decoding projects (for FLAC mostly). does this automatically do more than just the tracks? If not, how can I get the rest? - - Audio data prior to the start of track 1 (and possibly after the end of the 'last' track, depending on the disc layout) - - Sub-code index information -

I've just started to archive my CD collection (about 800 CDs), and my criteria are pretty much the same as the original message under this subject, except that I'm doing one file per CD. One file per song is just too much of a pain, and there's really no need, given FLAC's ability to have metadata in the file. The first thing I do is run cd-discid against the cd, and store that

Hi, Bit late to join in the discussion but I've just read through the CD archiving discussion and was particular interested in Dax's method, described here (also included below): http://lists.xiph.org/pipermail/flac/2006-September/000611.html So far I've just been flac-ing my CDs to individual one-flac-per-track files, however it appears I've been missing some of the other bits

Hi all, I've got a strange problem. I was just encoding a new CD I bought a couple of days ago (Muse - Hullabaloo Soundtrack) when I ran into a strange bug. After ripping track 8, CD 1 with cdparanoia under OpenBSD/alpha, I wanted to encode it with oggenc (latest version from the OpenBSD-current ports tree, (`oggenc -v` says 'OggEnc v1.0 (libvorbis 1.0)')). Here's the output :

Charles Steinkuehler wrote: > Dan Phillips wrote: > >> With regards the toc problem not compensating for starting from track > >> 0, is it possible to use the cdrtoa -t or -T options to compensate for > >> the shift. I am not sure I fully understand the option, but I came > >> across it and thought I would mention it. > > I believe the -T and -t flags

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dan Phillips wrote: > With regards the toc problem not compensating for starting from track > 0, is it possible to use the cdrtoa -t or -T options to compensate for > the shift. I am not sure I fully understand the option, but I came > across it and thought I would mention it. I believe the -T and -t flags (to cdparanoia? AFAIK, cdrdao

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Hirsch wrote: > >>> >>> I've been working on this sort of approach using abcde as a front-end, >>> and have run into several issues. What I finally decided on doing is >>> ripping the CD to a single flac file with embedded cue sheet using a >>> variety of tools (more details later). The

Greetings, I really love the one flac per cd idea. So, I pulled all my cds out of storage to re-encode them. I've run into a couple of general issues here: I've done some comparisons between eac under windows, and cdrdao under linux. It seems that after converting the cdrdao data to .wav, both programs result in perfectly identical .wav files for the 3 cds I tested. However,