You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(6) |
Jul
(5) |
Aug
(55) |
Sep
(16) |
Oct
(28) |
Nov
(35) |
Dec
(19) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(12) |
Feb
(15) |
Mar
(14) |
Apr
(27) |
May
(35) |
Jun
(42) |
Jul
(22) |
Aug
(21) |
Sep
(62) |
Oct
(52) |
Nov
(49) |
Dec
(14) |
2003 |
Jan
(11) |
Feb
(41) |
Mar
(16) |
Apr
(18) |
May
(9) |
Jun
(8) |
Jul
(9) |
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
(6) |
Dec
(5) |
2004 |
Jan
(13) |
Feb
(32) |
Mar
(10) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(12) |
Aug
|
Sep
(2) |
Oct
|
Nov
(6) |
Dec
|
2005 |
Jan
(1) |
Feb
(7) |
Mar
(4) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(7) |
Aug
|
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(4) |
2006 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
2007 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(7) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(10) |
Mar
|
Apr
|
May
(9) |
Jun
(4) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(1) |
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Andy Y. <And...@bb...> - 2014-10-20 08:30:39
|
Hello. I am using cdrdao for a large internal ripping project. All CDRs are from our internal archives and therefore not cross verifiable of any sort of CDDB. Most of the discs have track pre-gaps, and I am having slightly undefined behaviour and would appreciate an explanation if anyone can help. If I run a track pre-gap detection pass, I get TOC contents that I can recreate across different brands of DVD recorder. Command line for track pre-gap detection pass: cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_full_toc.toc If I try to use the TOC that's created as part of the cd read process I get slightly different different toc contents depending on the drive used. cdrdao read-cd -v 3 --driver generic-mmc --device /dev/sr1 --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_readcd.toc With a given sample disc, I get the following results for the disc "start" in the TOC: Plextor drive: Track 0: 00:00:00, Track 1: 00:00:07, Track 2: 00:00:12 Dell drive: Track 0: 00:00:00 , Track 1: 00:00:07, Track 2: 00:00:23 Read-TOC (Plextor and Dell): Track 0: 00:00:00 , Track 1: 00:01:73, Track 2: 00:01:73 The Read-TOC result of 00:01:73 is what appears to be correct. My main question is, whether the TOC information from the read-cd command is completely arbitrary or based on some parameter I don't understand fully. ( In this disc instance the Dell 00:00:23 frame Vs Plextor 00:00:12 frame track pre-gap difference in the resulting TOC file causes the cut to happen slightly in the wrong place and I get about 1/7th of a second of tone from the start of track #3 bleeding into the end of silence at the end of track #2. ) One other think of note is that if I try to fast read the TOC to ignore track pre gaps entirely, the offsets are wrong as the CD image file appears to contain the track pre-gaps within, so the cuts are in the wrong place. cdrdao read-toc -v 3 --driver generic-mmc --device /dev/sr1 --fast-toc --paranoia-mode 3 --buffers 123 --datafile ABC123.bin ABC123_fast_toc.toc The ultimate aim is to rip with cdrdao, then use toc2cue, then bchunk to split the CD images into WAV files. Thanks in advance for any enlightenment! Andy Young Systems Specialist Digital Media Services ---------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ---------------------------- |
From: <th...@ap...> - 2014-07-16 04:04:49
|
This mail announces the release of Morituri 0.2.3 'moved'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: <th...@ap...> - 2013-07-30 17:22:31
|
This mail announces the release of Morituri 0.2.2 'my bad'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: <th...@ap...> - 2013-07-15 08:14:33
|
This mail announces the release of Morituri 0.2.1 'married'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: <th...@ap...> - 2012-11-23 19:13:31
|
This mail announces the release of Morituri 0.1.3 'cranes'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: Andreas R. <and...@gm...> - 2012-01-22 21:15:45
|
Dear all, while testing Ardour's (www.ardour.org) TOC file generation routines, I found that while cdrdao uses the backslash in TOC files for escaping double quotes and allowing for octal notation of characters it *does not* allow the backslash itself to be escaped. To avoid any trouble a program generating a toc file will have to write a normal backslash in octal notation. Which is fine, but probably should be documented. No what I have trouble with is that cdrdao does not do that itself when writing a toc file while reading a CD. Example: Use any toc/wav image with CD text you have around, change the CD title to: TITLE "MyTestDisc\134" The \134 will be correctly interpreted as backslash and written as such onto your CD. Now when you rip the same CD with cdrdao, the resulting toc has: TITLE "MyTestDisc\" which, when fed to cdrdao will break the toc parser. Is there any specific reason of this behaviour? Are any programs using cdrdao relying on this behaviour? And if not, what's the best place to upload a patch? Best regards Andreas |
From: Mitch W. <fmw...@ya...> - 2011-12-06 17:43:09
|
All, I managed to successfully compile, install and run cdrdao-1.2.3 under Cygwin on Windows Vista, and could burn a playable disc. I don't know how to specify exactly what version of Cygwin I have, but it's not real new. The Windows is pretty much up to date with patches. I used the following configuration options: --without-lame --with-scglib --without-xdao --mandir=/usr/local/share/man --infodir=/usr/local/share/doc The --with-scglib option was necessary. Note that the discussion of the --with-scglib option in the INSTALL file included with cdrdao-1.2.3 is wrong. I had to add a file named os-cygwin_nt-6.0.id to the scsilib/RULES directory. I just copied it from os-cygwin_nt-5.1.id. It seems likely that an os-cygwin_nt-7.0.id file would be needed for Windows 7. Finally, I had to set 'ac_cv_no_user_malloc=yes' in the make command line. That is, the make command line was 'ac_cv_no_user_malloc=yes make' but then the install command line was just 'make install'. This was necessary because the build process for scsilib would freeze when trying to figure out how to set ac_cv_no_user_malloc. I didn't try to figure out whether this was a Cygwin thing or was specific to the version of gcc that I had. Also, the build process for scsilib seems to duplicate some of what the overall cdrdao configure process does. This at least slows things down unnecessarily. The good news, though, is that cdrdao built this way will burn a playable CD. The OS-level device locking still doesn't work. Mitch |
From: <th...@ap...> - 2011-06-05 16:28:47
|
This mail announces the release of Morituri 0.1.2 'VCR'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: Thomas V. S. <th...@ap...> - 2011-05-22 16:00:50
|
I got a bug report on morituri that makes me question the way cdrdao writes out extracted .toc data. The bug report is here: https://thomas.apestaart.org/morituri/trac/ticket/47 my understanding of cdrdao's behaviour is: - all non-ASCII characters get encoded using backslash-octal notation. - a backslash in CDTEXT data gets left as is AFAICT this means that there's no good way, when decoding a .toc file, to handle both cases correctly. Should this be considered as a bug in cdrdao ? Thomas -- -- Just because this is never going to work, there's no need to be negative. -- GStreamer - bringing multimedia to your desktop http://gstreamer.freedesktop.org/ |
From: Christian <Chr...@gm...> - 2011-02-03 17:18:36
|
Hello to everybody, I have a special idea about some sor of art. I want to send the raw data to my burner so I can completely control what will be written on the cd. My intension is not to write correct data or music to the cd. I want to make a sort of image on the cd. Therefore I do not need the control stuff and all that. I just want to give the exact continous series of 1s and 0s to create a desired pit/land topology. Do you understand what I mean? Is cdrdao able to help me doing this? I thouht of the generic-mmc-raw driver. Or do you have any suggestions to me how to solve my problem? Thanks in advance Christian |
From: Grant <ema...@gm...> - 2010-07-16 05:38:41
|
>>> I love cdrdao and I've been using it to rip CDs for a long time. >>> Recently I ran across 2 CDs that it has a problem ripping. Both are >>> The Beatles remastered Enhanced CDs "Please Please Me" and "With The >>> Beatles". cdrdao seems to have a problem detecting the end point of >>> the last audio track. I've attached the output of the read-cd >>> command. After splitting according to cdrdao's toc, the 14th track >>> includes about a minute of silence on the end followed by another >>> minute of a buzzing noise. Another annoyance is the fact that the >>> non-audio data portion of the Enhanced CD ends up being split and >>> encoded to flac as track 15 based on cdrdao's toc. >>> >>> - Grant >> >> I should mention that rubyripper creates the cuesheet correctly. I'd >> really like to stick with cdrdao though. >> >> - Grant > > This problem is actually documented here: > > http://en.wikipedia.org/wiki/Enhanced_CD > > "Sometimes computer CD-ripping programs (particularly cdparanoia) have > problems ripping some enhanced CDs, especially those that have the > data in a separate session after the audio section. These CDs have the > data 11,400 sectors (2m32s) after the audio, but some CD rippers may > try to rip this blank section with the last track; the end result is > that the ripper stalls during the last track, or simply reports > errors." > > - Grant I should also mention that it works correctly in rubyripper, and actually works in cdrdao maybe 10% of the time so it's inconsistent in cdrdao. - Grant |
From: Grant <ema...@gm...> - 2010-07-16 01:13:10
|
>> I love cdrdao and I've been using it to rip CDs for a long time. >> Recently I ran across 2 CDs that it has a problem ripping. Both are >> The Beatles remastered Enhanced CDs "Please Please Me" and "With The >> Beatles". cdrdao seems to have a problem detecting the end point of >> the last audio track. I've attached the output of the read-cd >> command. After splitting according to cdrdao's toc, the 14th track >> includes about a minute of silence on the end followed by another >> minute of a buzzing noise. Another annoyance is the fact that the >> non-audio data portion of the Enhanced CD ends up being split and >> encoded to flac as track 15 based on cdrdao's toc. >> >> - Grant > > I should mention that rubyripper creates the cuesheet correctly. I'd > really like to stick with cdrdao though. > > - Grant This problem is actually documented here: http://en.wikipedia.org/wiki/Enhanced_CD "Sometimes computer CD-ripping programs (particularly cdparanoia) have problems ripping some enhanced CDs, especially those that have the data in a separate session after the audio section. These CDs have the data 11,400 sectors (2m32s) after the audio, but some CD rippers may try to rip this blank section with the last track; the end result is that the ripper stalls during the last track, or simply reports errors." - Grant |
From: Grant <ema...@gm...> - 2010-07-16 00:47:10
|
> I love cdrdao and I've been using it to rip CDs for a long time. > Recently I ran across 2 CDs that it has a problem ripping. Both are > The Beatles remastered Enhanced CDs "Please Please Me" and "With The > Beatles". cdrdao seems to have a problem detecting the end point of > the last audio track. I've attached the output of the read-cd > command. After splitting according to cdrdao's toc, the 14th track > includes about a minute of silence on the end followed by another > minute of a buzzing noise. Another annoyance is the fact that the > non-audio data portion of the Enhanced CD ends up being split and > encoded to flac as track 15 based on cdrdao's toc. > > - Grant I should mention that rubyripper creates the cuesheet correctly. I'd really like to stick with cdrdao though. - Grant |
From: Grant <ema...@gm...> - 2010-07-15 02:12:55
|
I love cdrdao and I've been using it to rip CDs for a long time. Recently I ran across 2 CDs that it has a problem ripping. Both are The Beatles remastered Enhanced CDs "Please Please Me" and "With The Beatles". cdrdao seems to have a problem detecting the end point of the last audio track. I've attached the output of the read-cd command. After splitting according to cdrdao's toc, the 14th track includes about a minute of silence on the end followed by another minute of a buzzing noise. Another annoyance is the fact that the non-audio data portion of the Enhanced CD ends up being split and encoded to flac as track 15 based on cdrdao's toc. - Grant |
From: Denis L. <de...@po...> - 2010-05-24 08:26:36
|
On 05/23/2010 07:00 AM, Daniel Clark wrote: > Anyone successful in getting this to build, on solaris? I've always read on > > the homepage, that cdrdao is reported to work on solaris. I've never > > touched base with anyone who actually compiled it from source. Googling > > has been a dead end so far. We don't have a Solaris maintainer per se. I'm convinced it should require minimal work though, so if you give it a shot, please send me the patches. -denis |
From: Daniel C. <cla...@gm...> - 2010-05-23 05:00:55
|
Anyone successful in getting this to build, on solaris? I've always read on the homepage, that cdrdao is reported to work on solaris. I've never touched base with anyone who actually compiled it from source. Googling has been a dead end so far. |
From: <th...@ap...> - 2010-04-16 22:12:22
|
This mail announces the release of Morituri 0.1.1 'Dead'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: Thomas P. <tp...@gm...> - 2009-11-13 21:53:38
|
Denis Leroy (de...@po...) wrote: > I've released cdrdao 1.2.3 in SourceForge. ChangeLog below. > o Cygwin compilation fixes. Other various compilation warning > fixes. (Denis Leroy) I tried to compile cdrdao under cygwin, but it stops with undefinded references about ScsiIf. Please have a look at the attached logfile. Any help would be appreciated. -- mfg Thomas |
From: Denis L. <de...@po...> - 2009-10-05 15:21:42
|
I've released cdrdao 1.2.3 in SourceForge. ChangeLog below. -------------------------------------------------------------------------- cdrdao 1.2.3 (2009-10-05) -------------------------------------------------------------------------- o By default, cdrdao tries to build with a native SCSI interface. Use "--with-libscg" to use bundled libscg library. (Denis Leroy) o Complete rewrite of native Linux SG driver for SG 3.0 using SG_IO ioctl. That should make it behave better with ConsoleKit based permissions environment. Cdrdao should now be compiled on Linux without cdrtools by using "--without-scglib". (Denis Leroy) o Added support for new FIRST_TRACK_NO keyword to allow a CD to start with a track number other than 1. (Edgar Fuss) o Added native interfaces for Irix, Mac OSX and NetBSD. (Edgar Fuss) o Fixed old pregap length off-by-one error, see bug #604751 (Thomas Vander Stichele) o Fixed bug in Toc file parser track length computation. (Denis Leroy) o Man page typo fixes. (Denis Leroy) o Cygwin compilation fixes. Other various compilation warning fixes. (Denis Leroy) o Some scsilib fixes for FreeBSD, 32-bit and 64-bit SPARC. (Marius Strobl) o Some makefile changes to avoid conflict with installed system libs. (Marius Strobl) o Added patch to fix ARM and MIPS scsilib compile (Kedar Sovani, Debian) o Added man pages for toc2cue and toc2cddb, from Debian. o Move privilege drop earlier in main flow (based on Debian patch) o Commited Gentoo patch for CD-TEXT track check fix (Grant, Peter Alfredsen) GCDMaster changes: o Preferences now stored in GConf, exports schema file (Denis Leroy) o Added simple Preferences dialog to change temporary file directory (Denis Leroy) o Fixed GCC 4.3 compilation issues (Denis Leroy) |
From: <th...@ap...> - 2009-09-26 16:33:40
|
This mail announces the release of Morituri 0.1.0 'Youngblood'. Morituri is a CD ripper aiming for maximum quality. For more information, see http://thomas.apestaart.org/morituri/trac/ To file bugs, go to https://thomas.apestaart.org/morituri/trac/newticket |
From: j t <ma...@gm...> - 2009-07-03 21:53:33
|
On Fri, Jul 3, 2009 at 10:34 AM, Thomas Vander Stichele<th...@ap...> > I'm working on a cd ripper that at least quality-wise is comparable to > EAC. > Thomas Thomas, just a pointer in case you haven't already seen it: http://gna.org/projects/cued With kindest regards, Jaime |
From: Thomas V. S. <th...@ap...> - 2009-07-03 09:35:05
|
On Fri, 2009-07-03 at 11:05 +0200, Denis Leroy wrote: > On 07/03/2009 10:03 AM, Thomas Vander Stichele wrote: > > As a further data point, I did the following: > > > > - read-cd cure.toc > > - write cure.toc > > - read-toc cure2.toc > > > > ie, reading a cd, writing it again, then reading the written CD. > > > > As you can clearly see from the attachments, there is an off-by-one > > error on the frame calculation somewhere. I'm going to assume it's in > > the reading part after comparing with EAC. > > > > In the bug tracker, I found > > https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 > > > > which looks like my bug. > > > > I'll attach my findings there. > > > > It would be nice to get this fixed, but meanwhile I'll work around it. > > I hope I get told though when this gets fixed :) Otherwise my workaround > > will get it wrong when it does. > > Thomas, I'll try to address this bug within next week, but it's tricky > as this is really in the parsing core of cdrdao, which unfortunately I > am not super familiar with. What is it parsing at that point ? subchannels ? I'm not 100% sure I've pinpointed the bug, I'm trying with more discs. I've found one disc where it actually gets 100% correct pre-gap lengths, which is annoying as it means that for now I don't even have a correct workaround. > > What is 'EAC' ? Exact Audio Copy, a Windows program considered by many to be the reference. I'm working on a cd ripper that at least quality-wise is comparable to EAC. > Also, have you tried the patch that is in bug 604751 first comment ? Not yet; it's obvious what the patch does, but I don't understand enough of the subclass code there for the various drivers and I doubt only the generic one would need fixing. And so far I'm not sure I"ve pinpointed the bug yet... Someone providing some confirmation would be good. Thomas -- Being hung over is like winning the lottery, except they pay you in regret! -- Flumotion - the only way to stream! http://www.flumotion.net/ |
From: Denis L. <de...@po...> - 2009-07-03 09:06:10
|
On 07/03/2009 10:03 AM, Thomas Vander Stichele wrote: > As a further data point, I did the following: > > - read-cd cure.toc > - write cure.toc > - read-toc cure2.toc > > ie, reading a cd, writing it again, then reading the written CD. > > As you can clearly see from the attachments, there is an off-by-one > error on the frame calculation somewhere. I'm going to assume it's in > the reading part after comparing with EAC. > > In the bug tracker, I found > https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 > > which looks like my bug. > > I'll attach my findings there. > > It would be nice to get this fixed, but meanwhile I'll work around it. > I hope I get told though when this gets fixed :) Otherwise my workaround > will get it wrong when it does. Thomas, I'll try to address this bug within next week, but it's tricky as this is really in the parsing core of cdrdao, which unfortunately I am not super familiar with. What is 'EAC' ? Also, have you tried the patch that is in bug 604751 first comment ? -denis |
From: Thomas V. S. <th...@ap...> - 2009-07-03 08:03:52
|
As a further data point, I did the following: - read-cd cure.toc - write cure.toc - read-toc cure2.toc ie, reading a cd, writing it again, then reading the written CD. As you can clearly see from the attachments, there is an off-by-one error on the frame calculation somewhere. I'm going to assume it's in the reading part after comparing with EAC. In the bug tracker, I found https://sourceforge.net/tracker/?func=detail&aid=604751&group_id=2171&atid=102171 which looks like my bug. I'll attach my findings there. It would be nice to get this fixed, but meanwhile I'll work around it. I hope I get told though when this gets fixed :) Otherwise my workaround will get it wrong when it does. Thomas On Thu, 2009-07-02 at 23:19 +0200, Thomas Vander Stichele wrote: > On Sat, 2009-06-06 at 19:08 +0200, Thomas Vander Stichele wrote: > > Hi, > > > > I noticed that cdrdao's toc extraction always lists the length of the > > pregap as one frame shorter than EAC. For example, on Muse's Black > > Holes and revelations: > > > > - cdrdao lists, for track 11: > > // Track 11 > > TRACK AUDIO > > NO COPY > > NO PRE_EMPHASIS > > TWO_CHANNEL_AUDIO > > ISRC "GBAHT0500600" > > FILE "data.wav" 39:23:53 06:07:22 > > START 00:00:37 > > > > - EAC has: 0:00:00.38 in the ui > > > > Is it possible cdrdao has an off-by-one error here ? How can I verify > > whether it's cdrdao or EAC getting it wrong ? > > Anyone an idea ? I've verified this on two different drives, so I'm > pretty sure I'm not seeing things. > > Could someone try and confirm or deny ? > > Thanks > Thomas > -- The only thing I understood where the comma's. -- Flumotion - the only way to stream! http://www.flumotion.net/ |
From: Thomas V. S. <th...@ap...> - 2009-07-02 21:19:10
|
On Sat, 2009-06-06 at 19:08 +0200, Thomas Vander Stichele wrote: > Hi, > > I noticed that cdrdao's toc extraction always lists the length of the > pregap as one frame shorter than EAC. For example, on Muse's Black > Holes and revelations: > > - cdrdao lists, for track 11: > // Track 11 > TRACK AUDIO > NO COPY > NO PRE_EMPHASIS > TWO_CHANNEL_AUDIO > ISRC "GBAHT0500600" > FILE "data.wav" 39:23:53 06:07:22 > START 00:00:37 > > - EAC has: 0:00:00.38 in the ui > > Is it possible cdrdao has an off-by-one error here ? How can I verify > whether it's cdrdao or EAC getting it wrong ? Anyone an idea ? I've verified this on two different drives, so I'm pretty sure I'm not seeing things. Could someone try and confirm or deny ? Thanks Thomas -- In a city that kills by constriction throw your streets around me and squeeze -- savon - Saving your work to svn https://apestaart.org/thomas/trac/ |