From: Nix on
On 31 Jan 2010, unruh(a)wormhole.physics.ubc.ca uttered the following:

> On 2010-01-31, Nix <nix-razor-pit(a)esperi.org.uk> wrote:
>> On 30 Jan 2010, Joerg Schilling told this:
>>
>>> In article <slrnhm6t46.nn.pm(a)nowster.eternal-september.org>,
>>> Paul Martin <pm(a)nowster.org.uk> wrote:
>>>
>>>>> Now one could write a wrapper program for the library which would then
>>>>> be called by the GUI.
>>>>
>>>>You don't need root privileges to write to a CD or DVD writer under
>>>>Linux.
>>>
>>> Given the fact that your other claims prove that you are missing the needed
>>> skills on Linux to be able to judge on this, the best fit reply would be:
>>> you are uninformed and thus wrong.
>>
>> Gosh I wonder why nobody wants to use your software. It's really a mystery.
>
> Everyone uses his software. It is the dominant software on Linux for
> writing cds, dvds, etc. cdrkit is mostly software that he wrote.

Yes. I don't know anyone who's ever interacted with him who's not
looking for a replacement, but there aren't many good ones. It's like
glibc, only at least some of glibc's maintainers are reasonable.
From: Jim Lesurf on
In article <hp8h37-tdd.ln1(a)neptune.markhobley.yi.org>, Mark Hobley
<markhobley(a)hotpop.donottypethisbit.com> wrote:

> It depends on the input impedance of the sound card. It it is purely
> resistive, then you are right. A 2K ioe 10K reisistor in series would
> provide attenuation.

> I have not tried this, but I was thinking of an in series for
> attenuation and a parallel across the lines to retain the impedance.
> Maybe you need a couple of isolation capacitors too, but these are
> probably not necessary. You could probably get away with a "twist the
> wires together and apply electrical tape" job if you wanted to test this.

FWIW It might be more convenient to use something like a stereo volume pot.
Say a 20k one by a decent maker. That way you don't need to have to guess
in advance what level of attenuation you need, and can alter it in use as
you prefer.

More generally, having read this sub-thread the following might be of
interest.

I have tended to use dedicated audio recorders. Prefer these to using a
computer as recording hardware for various reasons.

For general purposes like making CDRs of old LPs and tapes you might find a
secondhand Pioneer 509 or 609 audio recorder is convenient. This can also
be used as a good audio CD player. Also has the ability to automatically
'track' the recording by sensing silent passages - but I personally never
use feature.

For higher quality (i.e. higher bitrates, 24bit, etc) I'm now using a
Tascam HD P2 'portable recorder'. This records onto CF cards which I can
then attach to the various computers I have via a card reader. Only had
this a few weeks and been testing it. So far it works well. e.g. can
deliver THD down to 0.001% and no sign of hum, etc. Since it makes
recordings onto CF card the max length of a recording is determined by the
size of the CF card. (Long recordings are automatically split into files
whose size limit you can specify with 1.5GB per file being the default.)

Testing the HD P2 prompted me to suggest the 20k pot as an attenuator as I
am currently using something like this with the HD P2 as it expects to see
inputs up to 0dBu (0.775V) but some sources like CD players can output over
2V. So having a variable attenuator can be useful.

The recordings are Broadcast Wave and in a directory structure with xml
files. But I am able to read and process these OK.

The advantage of the above is that once the recording system works you
don't have to worry about changing computer hardware or updating your OS,
etc. Provided the machines can read/write CDR/W and CF you are still in
bizness. :-)

For 'historic' reasons I've tended in the past to do all my editing of
recordings on a RISC OS machine. But am currently slowing spreading across
to using the Linux boxes I mention below.

Having said all the above there is one thing I'll ask about.

I'm using Ubuntu 9.10 on a Shuttle as well as Xubuntu 9.10 on an Acer
laptop. The Shutlle has a 'firewire' (4 pin) socket and the HD P2 has a (6
pin) socket. The HD P2 documents say it should appear as a hard drive via
firewire and - IIUC should be a standard mass storsge device. But when I
try connecting them the Shuttle and HD P2 don't notice.

I did a few quick searches for Ubuntu and Firewire for this, but couldn't
fine anything relevant. So should this work? Can someone point me at info
on how to do this? Using CF cards is OK, but having the firewire to the
Shuttle would be convenient as the Shuttle is also part of my main audio
system.

Slainte,

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

From: Mark Hobley on
Richard Kettlewell <rjk(a)greenend.org.uk> wrote:
> Using software involves making a copy of it (for instance, copying from
> disk to RAM). These copies indeed restricted by copyright law (CDPA1988
> 17(6)). So copyright law does control using software.

The copy in RAM is required for the software to be operable and is not
distributed. I doubt that making a copy of software from disk to RAM for
the purpose of using the software would be considered to be a violation of
copyright.

Mark.

--
Mark Hobley
Linux User: #370818 http://markhobley.yi.org/

From: Richard Kettlewell on
markhobley(a)hotpop.donottypethisbit.com (Mark Hobley) writes:
> Richard Kettlewell <rjk(a)greenend.org.uk> wrote:

>> Using software involves making a copy of it (for instance, copying from
>> disk to RAM). These copies indeed restricted by copyright law (CDPA1988
>> 17(6)). So copyright law does control using software.
>
> The copy in RAM is required for the software to be operable and is not
> distributed.

Indeed, but where does the law draw any distinctions on that basis?

> I doubt that making a copy of software from disk to RAM for the
> purpose of using the software would be considered to be a violation of
> copyright.

You may be right, but clause 17 suggests otherwise.

--
http://www.greenend.org.uk/rjk/
From: unruh on
On 2010-02-07, Paul Martin <pm(a)nowster.org.uk> wrote:
> In article <7siunbF6hcU1(a)mid.dfncis.de>,
> Joerg Schilling wrote:
>
> cdrecord needs:
>
> - CAP_DAC_OVERRIDE
> Bypass file read, write, and execute permission checks. (DAC is
> an abbreviation of "discretionary access control".)
>
> I can't see why it would require that at all!
>
> - CAP_IPC_LOCK
> Lock memory (mlock(2), mlockall(2), mmap(2), shmctl(2)).
>
> Useful, but in no way essential. It works OK without it.
>
> - CAP_SYS_NICE
> * set real-time scheduling policies for calling process, and set
> scheduling policies and priorities for arbitrary processes
> (sched_setscheduler(2), sched_setparam(2));
>
> Nope. I've never needed real time priority to burn a CD on recent
> CPUs.
>
> Burnproof (and similar) works. I know you don't think so, but it does.

Just because something works for you does not mean it works for
everyone. Schilling writes the program so it works for as broad a range
of systems as possible. He did not write it just for you and your
particular and peculiar hardware.


>
> - CAP_SYS_RAWIO
> Perform I/O port operations (iopl(2) and ioperm(2)); access
> /proc/kcore.
>
> Nope, not needed for /dev/sr0 type access. Nobody in their right mind
> uses the /dev/sg0 interface nowadays. It doesn't exist with the IDE
> drivers, anyway. (I do know about the newer ATA drivers, thank you.)

Again, you are generalising from a very peculiar personal situation.


>
> - CAP_NET_BIND_SERVICE
> Bind a socket to Internet domain privileged ports (port numbers
> less than 1024).
>
> What the heck does a CD recording program need that for?!
>
>> As most recent Linux distros do not support features to set these privileges
>> without first becomming root, it is still easier to just give root privileges
>> to cdrecord. Cdrecord has been audited for being installed suid root.
>
> Never heard of libpam? Obviously not.
>
> Sorry for taking so long to respond. I've had more pressing things to
> do than responding to such silliness.

You should have taken even longer.


>