[arch-general] ejecting after cdparanoia
I just used cdparanoia (for the very first time) and I tried to eject the CD by pressing the button. Nothing happens. I can eject the CD with "eject /dev/sr0", so it's not really a big problem. I just wonder whether this behavior is normal. I'm used to cdda2wav (from cdrtools), and it never happened, that I recall. Note that cdparanoia ended normally ( and successfully, BTW). I run it with speed 1. The drive is: $ cdrecord dev=1,0,0 -checkdrive Cdrecord-ProDVD-ProBD-Clone 3.00 (i686-pc-linux-gnu) Copyright (C) 1995-2010 Jörg Schilling scsidev: '1,0,0' scsibus: 1 target: 0 lun: 0 Linux sg driver version: 3.5.34 Using libscg version 'schily-0.9'. Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'PLEXTOR ' Identifikation : 'DVDR PX-L890SA' Revision : '1.02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE AUDIOMASTER FORCESPEED Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R LAYER_JUMP cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. ~ $ pacman -Q cdparanoia cdparanoia 10.2-3 TIA Jorge Almeida
On Wed, Sep 14, 2011 at 1:12 AM, Jorge Almeida <jjalmeida@gmail.com> wrote:
I just used cdparanoia (for the very first time) and I tried to eject the CD by pressing the button. Nothing happens.
Does this fix the problem? $ echo 1000 > /sys/module/block/parameters/events_dfl_poll_msecs If so, you could add it to your rc.local until 3.1 is out. For more info about this issue see: <https://bugs.archlinux.org/task/25609>. Cheers, Tom
On Wed, Sep 14, 2011 at 12:26 AM, Tom Gundersen <teg@jklm.no> wrote:
On Wed, Sep 14, 2011 at 1:12 AM, Jorge Almeida <jjalmeida@gmail.com> wrote:
I just used cdparanoia (for the very first time) and I tried to eject the CD by pressing the button. Nothing happens.
Does this fix the problem?
$ echo 1000 > /sys/module/block/parameters/events_dfl_poll_msecs
Yes!
If so, you could add it to your rc.local until 3.1 is out. For more info about this issue see: <https://bugs.archlinux.org/task/25609>.
I'll live with it until kernel 3.1, rather than putting stuff in rc.local that I will forget about. Thanks Jorge
Jorge Almeida <jjalmeida@gmail.com> wrote:
I just used cdparanoia (for the very first time) and I tried to eject the CD by pressing the button. Nothing happens. I can eject the CD with "eject /dev/sr0", so it's not really a big problem. I just wonder whether this behavior is normal. I'm used to cdda2wav (from cdrtools), and it never happened, that I recall. Note that cdparanoia ended normally ( and successfully, BTW). I run it with speed 1. The drive is:
cdparanoia is a cdda2wav version from 1997 with some modifications. Cdparanoia is Linux/gcc only. There modifications are a layer on top of the read functions and below the data outout. As the cdparanoia development stopped in 2001, Heiko Eißfeldt and I took the paranoia extensions, converted them to a portable library (libparanoia) and enhanced the modern cdda2wav code with the features from libparanoia. As cdda2wav uses a better base of read functions (special [vendor tailored] SCSI functions instead of calling the simplified kernel CDDA audio functions), cdda2wav gives beter results than cdda2wav. I recommend to use cdda2wav for best audio extraction results and in order to be able to access meta data also. See man page on how to enable paranoia mode in cdda2wav. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Am Wed, 14 Sep 2011 10:44:05 +0200 schrieb Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling):
As the cdparanoia development stopped in 2001,
And that's why the latest upstream release is from 2008, the latest SVN commit was 15 months ago and the latest update in [extra] is from May 2011. Heiko
Heiko Baums <lists@baums-on-web.de> wrote:
Am Wed, 14 Sep 2011 10:44:05 +0200 schrieb Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling):
As the cdparanoia development stopped in 2001,
And that's why the latest upstream release is from 2008, the latest SVN commit was 15 months ago and the latest update in [extra] is from May 2011.
It may be that there are some minor changes that allow to compile with newer GCC versions..... It may be that there have been some changes that include bugfixes in the paranoia code that have been done in the cdrtools project earlier. I can confirm, that some new comments have been introduced as the code is hard to understand...... I however cannot see any new features or updates on the cdda2wav base code. and BTW: I made the paranoia code a portable reentrant library in April 2002 after Monty (the original author made clear that it is unlikely that there will be further releases for cdparanoia (*). Since May 2002, cdda2wav supports paranoia. The advantages from cdda2wav over cdparanoia are: - works on any platform - Compiles with any compiler - reentrant code that may even be used as shared library on Mac OS X - Using vendor specific optimized code that allows to read UN-CDs - Reports whether libparanoia did leave audible problems in the data - Support for hidden tracks - Support for extracting meta data from the CD - Support for CDDB - Support for *.inf files or BIN/CUE Cdparanoia can be seen as the demonstrator to verify that the paranoia idea is useful, but it leaves many wishes that people have since more than 10 years. If you find a single case where cdparanoia is better than cdda2wav, you found a bug in cdda2wav - and there was no bug report against cdda2wav since many years. *) we are still waiting for the 1999 announced "completely rewritten paranoia IV" Conclusion: Monty made us a great present with cdparanoia, but since more than 10 years, he is working on other topics that don't leave him time to work on cdparanoia. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
Am Wed, 14 Sep 2011 10:44:05 +0200 schrieb Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling):
I recommend to use cdda2wav for best audio extraction results and in order to be able to access meta data also.
And, btw., neither cdrecord nor cdda2wav are in the repos, not even in the AUR anymore. I guess there's a reason. Heiko
On Wed, Sep 14, 2011 at 3:03 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Wed, 14 Sep 2011 10:44:05 +0200 schrieb Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling):
I recommend to use cdda2wav for best audio extraction results and in order to be able to access meta data also.
And, btw., neither cdrecord nor cdda2wav are in the repos, not even in the AUR anymore.
I guess there's a reason.
Heiko
Check again ;P [karol@black ~]$ pkgfile cdda2wav extra/cdrkit extra/dvdrtools [karol@black ~]$ pkgfile cdrecord extra/cdrkit
Am Wed, 14 Sep 2011 15:06:51 +0200 schrieb Karol Blazewicz <karol.blazewicz@gmail.com>:
On Wed, Sep 14, 2011 at 3:03 PM, Heiko Baums <lists@baums-on-web.de> wrote:
Am Wed, 14 Sep 2011 10:44:05 +0200 schrieb Joerg.Schilling@fokus.fraunhofer.de (Joerg Schilling):
I recommend to use cdda2wav for best audio extraction results and in order to be able to access meta data also.
And, btw., neither cdrecord nor cdda2wav are in the repos, not even in the AUR anymore.
I guess there's a reason.
Heiko
Check again ;P
[karol@black ~]$ pkgfile cdda2wav extra/cdrkit extra/dvdrtools [karol@black ~]$ pkgfile cdrecord extra/cdrkit
I didn't say anything about cdrkit and dvdrtools. I talked about cdrecord and cdda2wav. Read the posting with the suggestion to using cdrecord and cdda2wav again and look who has written this posting. ;-P Heiko
Read the posting with the suggestion to using cdrecord and cdda2wav again and look who has written this posting. ;-P
Heiko
Ah, I get it now :-)
Karol Blazewicz <karol.blazewicz@gmail.com> wrote:
Read the posting with the suggestion to using cdrecord and cdda2wav again and look who has written this posting. ;-P
Heiko
Ah, I get it now :-)
BTW: a note.... cdrkit cannot be legally distributed and preserves a buggy state (+ extra Debian specific bugs) from September 2004. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 2:03 PM, Heiko Baums <lists@baums-on-web.de> wrote:
And, btw., neither cdrecord nor cdda2wav are in the repos, not even in the AUR anymore.
I guess there's a reason.
I'm sure there is, and I'm sure it's a good one for the devs. This doesn't mean it's a good reason, which for me would be a reason related with the quality of the software as opposed to related to the authors' personalities. For example, daemontools is not in the repos, whereas systemd is. I would prefer cdrtools in the repos, but it's no big deal, as it compiles easily and has no dependency hell. As for daemontools, I wouldn't make use of the repos version, if there were one, as I prefer to have it compiled statically against dietlibc. What I do hope devs will not force me to do is to have the kitchen sink (plus a sound server, probably) in process 1. The point is that quality should be the major criterium... Cheers. Jorge
Heiko Baums <lists@baums-on-web.de> wrote:
And, btw., neither cdrecord nor cdda2wav are in the repos, not even in the AUR anymore.
This looks like a bug as these programs are part of the standard optical media support package. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 9:44 AM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
cdparanoia is a cdda2wav version from 1997 with some modifications.
Even the recent version? Cdparanoia
is Linux/gcc only.
Tha'ts fine by me. I understand devs will think otherwise, but for a linux-only user portability is not a plus nor a minus.
I recommend to use cdda2wav for best audio extraction results and in order to be able to access meta data also.
Joerg: I've been using your software, and I intend to keep using it. Yes, I know about the -paranoia option. But sometimes cdda2wav report some (usually minor) problems. Example: 100% track 4 recorded with minor problems (0.2% problem sectors) 100% 0 rderr, 0 skip, 0 atom, 1 edge, 81 drop, 1 dup, 0 drift 100% 466 overlap(0.5 .. 0.8274) I suppose this is essentially harmless, but, being somewhat perfectionist, I would rather have 0 problems. Most tracks usually come out without errors. So I tried cdparanoia, and it did the ripping with two "+" signs at full speed. So I tried at speed=1 and it came out completely clean. Now, I'm not that naif as to assume that "no errors reported" <=> "no errors at all". (Maybe 0 errors from cdparanoia means that the 81 drops are still there but deemed irrelevant?) I did visit the cdparanoia site, but I didn't leave much wiser. So, for someone who wants to rip a brand new, duly purchased, never played before, CD with the maximum quality, what would be useful to know (with proper arguments) is: -- When one of the programs ("cdda2wav -paranoia" or "cdparanoia") reports less than optimal results, is it worth to try the other one? -- Note that this wouldn't mean that one is better than the other: they might use different algorithms, and it might happen that one algorithm performs better for a particular CD. Then again, what I'm saying may be complete nonsense. I am not qualified to read the source of either program. Thanks Jorge
Jorge Almeida <jjalmeida@gmail.com> wrote:
On Wed, Sep 14, 2011 at 9:44 AM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
cdparanoia is a cdda2wav version from 1997 with some modifications.
Even the recent version?
Cdparanoia
Correct, Monty did take a cdda2wav release from before the first major rewrite has been done. There was a major rewrite starting in 1999 another one starting around 2006.
is Linux/gcc only.
Tha'ts fine by me. I understand devs will think otherwise, but for a linux-only user portability is not a plus nor a minus.
All my software is portable to virtually all platforms and this is why I need to make code portable before I can ise it.
Joerg: I've been using your software, and I intend to keep using it. Yes, I know about the -paranoia option. But sometimes cdda2wav report some (usually minor) problems. Example:
100% track 4 recorded with minor problems (0.2% problem sectors) 100% 0 rderr, 0 skip, 0 atom, 1 edge, 81 drop, 1 dup, 0 drift 100% 466 overlap(0.5 .. 0.8274)
"minor problems" means that these problems are not expected to cause audible results. If you like to most agressive parameters, I recommend to call: cdda2wav paraopts=proof
I suppose this is essentially harmless, but, being somewhat perfectionist, I would rather have 0 problems. Most tracks usually come out without errors. So I tried cdparanoia, and it did the ripping with two "+" signs at full speed. So I tried at speed=1 and it came out completely clean.
This just verifies that cdparanoia doesn't inform you about the problems.
Now, I'm not that naif as to assume that "no errors reported" <=> "no errors at all". (Maybe 0 errors from cdparanoia means that the 81 drops are still there but deemed irrelevant?) I did visit the cdparanoia site, but I didn't leave much wiser. So, for someone who wants to rip a brand new, duly purchased, never played before, CD with the maximum quality, what would be useful to know (with proper arguments) is:
I fixed some problems in the praranoia code related to error reporting....
-- When one of the programs ("cdda2wav -paranoia" or "cdparanoia") reports less than optimal results, is it worth to try the other one?
My ststistic experience shows that you will usually not get a better overall result if you repeat the extract with all tracks as usually one track will be worse then before. I thus recommend to repeat extracting single tracks. Note: cdda2wav supports MD5 sums on the audio data since 2008. This allows an easy check on whether an identical result may give different paranoia statistics.
Note that this wouldn't mean that one is better than the other: they might use different algorithms, and it might happen that one algorithm performs better for a particular CD. Then again, what I'm saying may be complete nonsense. I am not qualified to read the source of either program.
Before 2006, cdda2wav did not enable dynamic overlap with libparanoia. This may cause different results. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 4:52 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
results. If you like to most agressive parameters, I recommend to call:
cdda2wav paraopts=proof
I'll keep this one in mind for next time.
come out without errors. So I tried cdparanoia, and it did the ripping with two "+" signs at full speed. So I tried at speed=1 and it came out completely clean.
This just verifies that cdparanoia doesn't inform you about the problems.
Nevertheless, it did inform about the two small problems corresponding to '+' (" Unreported loss of streaming/other error in read"), which disappeared when I repeated the ripping with speed 1.
-- When one of the programs ("cdda2wav -paranoia" or "cdparanoia") reports less than optimal results, is it worth to try the other one?
My ststistic experience shows that you will usually not get a better overall result if you repeat the extract with all tracks as usually one track will be worse then before. I thus recommend to repeat extracting single tracks.
Of course. What I do is to extract it all ("-B") and then try again for each track that didn't came out perfect ("-t n"). I even have the feeling that it may get better after letting the drive resting for a while, maybe heat is a problem...
Note that this wouldn't mean that one is better than the other: they might use different algorithms, and it might happen that one algorithm performs better for a particular CD. Then again, what I'm saying may be complete nonsense. I am not qualified to read the source of either program.
Before 2006, cdda2wav did not enable dynamic overlap with libparanoia. This may cause different results.
Can you positively confirm that there are no different algorithms in the two programs that might sometimes have influence? I used the current version from the Arch (extra/cdparanoia 10.2-3), which I suppose is not the one you mean. Jorge
Jorge Almeida <jjalmeida@gmail.com> wrote:
On Wed, Sep 14, 2011 at 4:52 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
results. If you like to most agressive parameters, I recommend to call:
cdda2wav paraopts=proof
I'll keep this one in mind for next time.
This is thwe latest important change incdda2wav and it allows to use a value that would need a second run if you like to do things manually: paraopts=proof means use overlap that is maxtransfer - 1 sector.
This just verifies that cdparanoia doesn't inform you about the problems.
Nevertheless, it did inform about the two small problems corresponding to '+' (" Unreported loss of streaming/other error in read"), which disappeared when I repeated the ripping with speed 1.
Did you also tell cdda2wav to use speed=1? If you cannot repeat this now, it would be impossible to find the reason now.
Of course. What I do is to extract it all ("-B") and then try again for each track that didn't came out perfect ("-t n"). I even have the feeling that it may get better after letting the drive resting for a while, maybe heat is a problem...
Temparature influences results.
Before 2006, cdda2wav did not enable dynamic overlap with libparanoia. This may cause different results.
Can you positively confirm that there are no different algorithms in the two programs that might sometimes have influence? I used the current version from the Arch (extra/cdparanoia 10.2-3), which I suppose is not the one you mean.
I fixed some bugs in cdparanoia (e.g. a buffer overflow problem and some problems in the code that creates the statistics). These problems most likely still exist in cdparanoia. Also note that cdparanoia uses the kernel interface to read audio data. This results in fewer reported errors and in worse data in some cases. The kernel uses simpler code and does not evaluate all error information that is checked by cdda2wav. The error report written by cdda2wav is a result of many tests with bad CDs that include listening to the results. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 6:40 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote: ng to '+' ("
Unreported loss of streaming/other error in read"), which disappeared when I repeated the ripping with speed 1.
Did you also tell cdda2wav to use speed=1?
Yes, I did that before trying cdparanoia.
If you cannot repeat this now, it would be impossible to find the reason now.
Well, I have the original CD, which I never used in a CD reader, as I currently use the computer to send the digital sound to the external converter, so the CD is like new. What would be useful to do to provide data? Jorge
Jorge Almeida <jjalmeida@gmail.com> wrote:
On Wed, Sep 14, 2011 at 6:40 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote: ng to '+' ("
Unreported loss of streaming/other error in read"), which disappeared when I repeated the ripping with speed 1.
Did you also tell cdda2wav to use speed=1?
Yes, I did that before trying cdparanoia.
If you cannot repeat this now, it would be impossible to find the reason now.
Well, I have the original CD, which I never used in a CD reader, as I currently use the computer to send the digital sound to the external converter, so the CD is like new. What would be useful to do to provide data?
The errors reported by cdda2wav may be reported by cdparanoia as a smiley that pops up for less than a second and then disappears. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 7:29 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
The errors reported by cdda2wav may be reported by cdparanoia as a smiley that pops up for less than a second and then disappears.
Are you sure those smileys won't get into the log file? I just tried a track of a CD which got errors in _all_ tracks with cdda2wav (it's one of a boxed set, and it is the only one that has this problem, bad quality control, I suppose). I didn't set the speed and I didn't move my eyes from the xterm. $ cdparanoia -L -l -d /dev/sr0 1 It didn't show anything wrong, just a '>' moving forward and ':-)' at the right side, which was substituted by ':^D' when finished. cdparanoia III release 10.2 (September 11, 2008) Ripping from sector 0 (track 1 [0:00.00]) to sector 27216 (track 1 [6:02.66]) outputting to cdda.wav (== PROGRESS == [ | 027216 00 ] == :^D * ==) Done. This was the log from cdda2wav: 100% track 1 recorded with minor problems (1.4% problem sectors) 100% 0 rderr, 0 skip, 0 atom, 383 edge, 1 drop, 0 dup, 1 drift 100% 371 overlap(0.5612 .. 40.29) Jorge
Jorge Almeida <jjalmeida@gmail.com> wrote:
On Wed, Sep 14, 2011 at 7:29 PM, Joerg Schilling
Are you sure those smileys won't get into the log file? I just tried a track of a CD which got errors in _all_ tracks with cdda2wav (it's one of a boxed set, and it is the only one that has this problem, bad quality control, I suppose). I didn't set the speed and I didn't move my eyes from the xterm.
$ cdparanoia -L -l -d /dev/sr0 1
It didn't show anything wrong, just a '>' moving forward and ':-)' at the right side, which was substituted by ':^D' when finished.
cdparanoia III release 10.2 (September 11, 2008)
Ripping from sector 0 (track 1 [0:00.00]) to sector 27216 (track 1 [6:02.66])
outputting to cdda.wav
(== PROGRESS == [ | 027216 00 ] == :^D * ==)
Done.
This was the log from cdda2wav:
100% track 1 recorded with minor problems (1.4% problem sectors) 100% 0 rderr, 0 skip, 0 atom, 383 edge, 1 drop, 0 dup, 1 drift 100% 371 overlap(0.5612 .. 40.29)
As mentioned before, cdparanoia has bugs that are not in cdda2wav. Cdda2wav correclty sums up all events but cdparanoia uses edge events (that also adjust the overlap area) to forget about previous errors. This is why you don't get a related error message from cdparanoia. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
On Wed, Sep 14, 2011 at 8:38 PM, Joerg Schilling <Joerg.Schilling@fokus.fraunhofer.de> wrote:
As mentioned before, cdparanoia has bugs that are not in cdda2wav.
Cdda2wav correclty sums up all events but cdparanoia uses edge events (that also adjust the overlap area) to forget about previous errors. This is why you don't get a related error message from cdparanoia.
OK, thanks Jorge
blah blah blah Get your own thread(s), will you. cdda2wav vs cdparanoia has nothing whatsoever to do with the topic. (If you forgot what the topic was, have a look at the subject line...)
-- cantabile "Jayne is a girl's name." -- River
On Thu, Sep 15, 2011 at 9:02 AM, cantabile <cantabile.desu@gmail.com> wrote:
blah blah blah Get your own thread(s), will you. cdda2wav vs cdparanoia has nothing whatsoever to do with the topic. (If you forgot what the topic was, have a look at the subject line...)
The thread was ended, as anyone who can read would have realized by reading the last post. Maybe you missed school the day they taught how to read? Or were you just too busy blahblablahing with your school pals?
participants (6)
-
cantabile
-
Heiko Baums
-
Joerg.Schilling＠fokus.fraunhofer.de
-
Jorge Almeida
-
Karol Blazewicz
-
Tom Gundersen