Announcing cdrskin-0.7.2.pl01
Hi, be invited to try the new version 0.7.2.pl01 of my program cdrskin, a burn backend for CD, DVD and BD with a command line interface compatible to cdrecord. System requirements: Linux with kernel 2.4 or 2.6: libc, libpthread or FreeBSD : libc, libpthread, ATAPI/CAM enabled, see atapicam(4) Changes: * Workaround for Pioneer DVR-216D which got stuck on DVD-R burns. * Workaround for Pioneer DVR-216D refusal to eject. For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html http://scdbackup.sourceforge.net/man_1_cdrskin.html Download: There is a cdrskin release tarball (containing libburn): http://scdbackup.sourceforge.net/cdrskin-0.7.2.pl01.tar.gz scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org . cdrskin is also part of the libburn-0.7.2 SVN tag: http://svn.libburnia-project.org/libburn/tags/ZeroSevenTwoPl01 (needs autotools = 1.7 to apply command ./bootstrap) and of the libburn-0.7.2 release tarball: http://files.libburnia-project.org/releases/libburn-0.7.2.pl01.tar.gz (needs only vanilla tools for ./configure ; make) Post bug reports or requests either to one of these mailing lists: mailto:libburn-hack...@pykix.org mailto:cdwrite@other.debian.org or directly to me: mailto:scdbac...@gmx.net Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, In burn_rspc_mult: Here is a more bullet-proof version of the second test: (((int)a - 1) | ((int)b - 1)) 0 Bullet-proof is more important than speed. Whatever, all variations had only negative effects. (I measure 10 * 800 MB in about 110 seconds. The negative effects are in the range of 10 to 20 seconds.) static unsigned char burn_rspc_div_3(unsigned char a) Given that gfpow is doubled, this code should be faster and simpler: Stupid me. The -25 case is unneeded, indeed. :)) Nevertheless the overall impact of the division is quite low. For 2352 bytes it happens 69 times. There are more than 4000 multiplications which each need about the same time as a division. My compliments for your knowledge about code optimizations. Your ideas are more elaborate than mine. It seems that gcc -O2 works best if one does not try to squeeze small details. (I would assume this is a property of the compiler and not so much of the processor.) Significant results came from: - Unrolling gfpow[] to 509 elements. - Uniting two pairs of loops which shared nearly the same index computation. Anything else had no effect or even hampered -O2. I made some of the neutral simplifications nevertheless. It cannot harm to have fewer C statements in the code. Besides the remaining opportunities for parallelisation maybe a less highschoolish method of solving HxV=0 might lead to better results. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, Why are the two logs added as integers (+) rather than as polynumials (^)? Why do you do % 255 rather than 256? Interesting point. The justification must be hidden in James S. Plank's statement: This implementation makes use of the fact that the inverse log of an integer is equal to the inverse log of (i mod (2^w - 1)). I'll try to find out why this is a fact and why this causes the + in the multiplication algorithm. (Any hint appreciated. It is half a life ago that i did sincere algebra.) Nevertheless i think this open question does not infringe the claim that ecma130ab.c implements ECMA-130 Annex A by help of well known mathematical methods. If you double the gfpow table's size you could elminate the % 255. This is well worth a try. I simplified the constant division by 3 but that happens not often enough to have much effect. One could also apply the division to the matrix H which currently is an alter ego of the power table. The index computation of burn_rspc_q0q1() can be done in part before the loop. Maybe one would have to explore the route via Fourier again for a really smart reformulation. Does ECMA provide any test vectors for you to test your code with? Unit tests might be very useful! I test against the old implementation which was once introduced by the founders of libburn. Nevertheless i am not sure whether that one really complies to ECMA-130. A test would be to blow up some data sectors and to burn them in raw mode. Then one would try to read them as data blocks. The drive's decoder would then deliver the original data if all went right. But for burning data sectors in raw mode there are more things to learn. Some i find in the MMC specs. Some are still obscure to me. By the code replacement i just want to keep up eventual old capabilities of libburn which i had to remove after Joerg's intervention a few weeks ago. - libburn does not stem from cdrtools. It rather appears to have originated as academic project which stalled when the semester was over. When i began to beef it up, it became obvious that its architecture was significantly more elaborate than the implementation code in its functions. See also Project history as far as known to me beginning in line 171 of http://libburnia-project.org/browser/libburn/trunk/README - Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, Why are the two logs added as integers (+) rather than as polynumials (^)? One can prove the theorem log(a*b) = log(a) + log(b) by a = x^log(a) b = x^log(b) a*b = x^log(a)*x^log(b) = x*x...x * x*x...x \/\/ log(a) many log(b) many This breaks down the computation to counting the number of polynomial multiplications. That counting happens on natural numbers, not on polynoms. I.e. the indice of the power and log table represent natural numbers, not polynomials. (The polynomial addition is not an iteration of increments, and the polynomial multiplication is not an iteration of polynomial additions. It is a bit mind twisting indeed if one does not base a field on an extension of the natural numbers.) Why do you do % 255 rather than 256? The periodicity of the x^n enumeration is 256-1 because the 0 does not participate. Similar as with groups the enumeration cycles through all other values until it hits its start value again. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, I have to correct myself: I.e. the indice of the power and log table represent natural numbers, not polynomials. The indice of the power table are natural numbers, the indice of the log table are polynomials. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, D. Hugh Redelmeier: If you double the gfpow table's size you could elminate the % 255. That was a substantial improvement. It now needs only 10 % more time than the old implementation. I.e. you cut off 80% of the initial performance deficit. One has to unroll the table gfpow[] up to 511 elements because the highest sum of two gflog[] elements is 510. My own optimization idea about Q index computation appears to have been anticipated by gcc -O2 already. But i was able to squeeze out the remaining 10 % by computing LSB and MSB of the 16 bit words in one loop rather than in two. Now it depends mainly on external influences which of both algorithms wins the race. Maybe the old one is by an epsilon faster. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
D. Hugh Redelmeier h...@mimosa.com wrote: I'm not going to judge who is right and who is wrong. This is a long conflict, as far as I know. There is no related long conflict with libburn. You may confuse this with the conflict that has been initiated by a hostile Debian packaging person in May 2004 who did send repeated personal insults for more than a year just because he was unwilling to fix the bugs in a patch that he liked to be integrated into mkisofs. As a user, I'm thankful for Joerg *and* everyone else who has helped to develop this code. OSS code for larger projects is usually developed by more than one person and I believe that is is a matter of courtesy to mention the people who did write parts of the code. The cdrtools project does this and I would expect similar rules for other projects. While I can understand that someone might forget to mention some of the contributors, this does not apply to the current problem. As the maintainers from the libburn project claimed that they did not take any code from the cdrtools project although they did, I was asking them not to write claims that are obviously wrong. I hope this helps to understand the case. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
| From: Thomas Schmitt scdbac...@gmx.net | I have to correct myself: | I.e. the indice of the power and log table | represent natural numbers, not polynomials. | | The indice of the power table are natural | numbers, the indice of the log table | are polynomials. Thanks for your very useful explanations. The logs are whole numbers. I was taught that 0 is not included in natural numbers. This is a matter of dispute among mathematicians; see the first paragraph of: http://en.wikipedia.org/wiki/Natural_number As you explained elsewhere, they are actually the integers mod 255. As such, your original gfpow table should have had a size of 255 elements, not 256. Your initializer only initialized 255, leaving the last (unused) element to be implicitly initialized with 0. In fact, no entry of gfpow should be 0 because no power of x is 0. Luckily, that wrong entry would never be used. | One has to unroll the table gfpow[] up to 511 | elements because the highest sum of two gflog[] | elements is 510. The smallest log is 0. The largest is 254 (not 255). So the range of sums of pairs of logs is [0-508]. So you actually need only 509 elements in the expanded table. It seems easier to just double the table of 255 elements to 510 elements. I'm glad that eliminating the % made a significant speedup. That leads me to wonder about a different idea that might or might not cause a speedup. In burn_rspc_mult: 453if (a == 0 || b == 0) 454 return 0; On most modern machines, branches are slow. This test requires two branches. So it might be faster to use | in place of || because only one branch would be required. That depends on the compiler knowing how to calculate == without branching. If the compiler is not smart enough, this test should do the same job: ((a + 0xFF) (b + 0xFF) 0x100) == 0 Explanation: a + 0xFF will have the 0x100 bit on UNLESS a was zero. The result of the first will have that bit on unless either a or b was zero. So would this: ((a - 1) | (b - 1)) 0 Explanation: a - 1 will be less than 0 if and only if a was 0. The result of the | will be negative if and only if one of its operands was negative. This second test won't work on a class of machines that I've never seen: ones where sizeof(unsigned char) == sizeof(int). Why? Because C's promotion rules mean that a - 1 on such a machine would be done in type unsigned int, and thus the result could never become negative. (Actually, some compilers from before the C Standard have this too.) Here is a more bullet-proof version of the second test: (((int)a - 1) | ((int)b - 1)) 0 As you can see, these tricky tests require several extra operations to save a branch. I would expect that to be faster on most modern processors but I have not tested this. In burn_rspc_div, you return -1 if the division is by 0. -1 isn't really a nice unsigned char value. Do you know if this case ever comes up? If it should not, for some values of should, perhaps the function could abort instead. 467 d = gflog[a] - gflog[b]; 468 if (d 0) 469 d += 255; 470 return gfpow[d]; Now that you have the doubled table, I guess that this could be rewritten as: return gfpow[gflog[a] - gflog[b] + 255]; Looking at next_bit(). These comments are REALLY unimportant. - is there any reason that the 0x3fff is needed? How would the 0x8000 bit get set? - should the type of the result of next_bit (and ret) be unsigned short? 673 ecma_130_fsr = (ecma_130_fsr 1) 0x3fff; 674 if (ret ^ (ecma_130_fsr 1)) 675 ecma_130_fsr |= 0x4000; ecma_130_fsr = 1; ecma_130_fsr |= (ret ^ (ecma_130_fsr 1)) 14 Simpler? Several functions unconditionally return 1. For example burn_rspc_p0p1. In that case at least, the caller ignores the result. Why not define the function with a return type of void? -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi,
As such, your original gfpow table should have had a size of
255 elements, not 256.
Yes. It became obvious when i unrolled it.
I had just estimated its size to produce no
buffer overflows.
The operation % 255 makes index 255 impossible.
The smallest log is 0. The largest is 254 (not 255). So
the range of sums of pairs of logs is [0-508]. So you actually need
only 509 elements in the expanded table.
Right indeed. When i looked up the highest
value of gflog, i strayed into gfpow.
453if (a == 0 || b == 0)
I will test your proposals.
Some of my own experiments yielded surprising
setbacks. E.g. i replaced
gfpow[44 - i]
by
h45[i]
with a suitable constant array h45[].
This was 7 percent slower !
(I suspect a less fortunate cache situation.)
In burn_rspc_div, you return -1 if the division is by 0.
This has been replaced by a specialized
burn_rspc_div_3() which divides by (x^1+1).
Less ifs, less array lookups, but no speed-up:
/* Divides by polynomial 0x03. Derived from burn_rspc_div() */
static unsigned char burn_rspc_div_3(unsigned char a)
{
if (a == 0)
return 0;
if (gflog[a] = 25)
return gfpow[gflog[a] - 25];
else
return gfpow[230 + gflog[a]];
}
I trust in gcc -O2 that it handles the double
lookup of gfpow[a] properly.
The code swallowed far more obvious workload
improvements without showing speed reactions.
Looking at next_bit().
This only had to work properly once to produce
the initial content of array ecma_130_annex_b[].
No need to make it fast or to question its
C language correctness after it produced the
same pseudo-random string as used in the old
code.
Several functions unconditionally return 1.
Why not define the function with a return type of void?
I can indeed change the type now that it is
clear that there is only one return value.
I see some potential in parallelization.
We have at least 32 bit for exor operations.
There are two neighbored bytes multiplied by
the same byte simultaneously.
But already now a 1000 MHz CPU can easily feed
a 48x CD stream. I am not aware of faster CD
media. And this stuff is for CD only.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
| From: Thomas Schmitt scdbac...@gmx.net
| Some of my own experiments yielded surprising
| setbacks. E.g. i replaced
|gfpow[44 - i]
| by
|h45[i]
| with a suitable constant array h45[].
| This was 7 percent slower !
| (I suspect a less fortunate cache situation.)
Right. gcc can fold the constant 44 into indexing. You might have
saved a unary - operation, but I don't know. But, as you suggest, an
extra burden on a cache may be a problem.
Even worse: the price of a cache burden depends on the CPU's cache
implementation and size so testing on one machine does not give a fair
overview of performance on other machines.
| In burn_rspc_div, you return -1 if the division is by 0.
|
| This has been replaced by a specialized
| burn_rspc_div_3() which divides by (x^1+1).
| Less ifs, less array lookups, but no speed-up:
|
| /* Divides by polynomial 0x03. Derived from burn_rspc_div() */
| static unsigned char burn_rspc_div_3(unsigned char a)
| {
| if (a == 0)
| return 0;
| if (gflog[a] = 25)
| return gfpow[gflog[a] - 25];
| else
| return gfpow[230 + gflog[a]];
| }
Given that gfpow is doubled, this code should be faster and simpler:
| {
| if (a == 0)
| return 0;
| /* Note: gflog(x^1 + x^0) == 25 */
| return gfpow[(255 - 25) + gflog[a]];
| }
I think that 0x03 has a multiplicative inverse too. This would allow
a division to be replaced by a multiplication.
Since fglog(0x03) is 25, the multiplicative inverse ought to have a
gflog of -25 == 230. It turns out that gflog(244) == 230 so 244 ==
0xF4 appears to be the multiplicative inverse. It surprises me that
0xF4 + 0x03 == 0xFF (for either kind of +!).
So, not too surprisingly, 255-25 could be replaced by 0+230. No
advantage, just interesting. It still requires the gfpow table to be
doubled.
| I trust in gcc -O2 that it handles the double
| lookup of gfpow[a] properly.
Probably.
| The code swallowed far more obvious workload
| improvements without showing speed reactions.
Right. I'm shooting in the dark given that I'm not testing let alone
measuring.
|
|
| I see some potential in parallelization.
| We have at least 32 bit for exor operations.
| There are two neighbored bytes multiplied by
| the same byte simultaneously.
|
| But already now a 1000 MHz CPU can easily feed
| a 48x CD stream. I am not aware of faster CD
| media. And this stuff is for CD only.
OK.
Any further improvement should probably be guided by measuring for hot
spots.
--
To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
| From: Thomas Schmitt scdbac...@gmx.net | Do you know by chance a smart student who can | contribute an implementation or explanation of | ECMA-130 Annex A ? | | The RSPC is a product code over GF(28) producing | P- and Q-parity bytes. The GF(28) field is | generated by the primitive polynomial | P(x) = x8 + x4 + x3 + x2 + 1 | The primitive element a of GF(28) is | a = (0010) where the right-most bit is the | least significant bit. | [...] | | The words RSPC and P- and Q-parity bytes | belong to the CD sector format specs. But the | others must be established mathematic terms. | (How is this connected to a Fourier | transformation of the bit sequence on time | domain ? Urgh ! Analysis ! On a finite set !) I am not a mathematician. I'd guess that this is really GF(2^8). GF stands for Gallois Field. Gallois Fields have size p^m where p is a prime (in our case, 2). Ahh. The standard confirms this: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-130.pdf Thus all elements of GF(2^8) would be polynomials of degree 7 or less. The coefficients are from the integers mod 2 and thus any polynomial in this field can be represented as 8 bits. The primitive polynomial would be: P(x) = x^8 + x^4 + x^3 + x^2 + x^0 See http://en.wikipedia.org/wiki/Finite_field RSPC seems to be Reed-Solomon Product-like Code. See http://en.wikipedia.org/wiki/Finite_field From that article, it looks as if the discrete Fourier transform you require can be done by a cook book method: http://en.wikipedia.org/wiki/Berlekamp-Massey_algorithm I admit that I'm shooting from the hip here. But it seems as if the internet has enough information to get to a solution. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
The Problem is however, The problem is however that you are highly annoying. With the plans for libburnia website revamp, there is a plan to provide a replacement list for this list, where we would help any users, regardless of the software they use. Even if we have it now, its a bit under-promoted and has some spam. It'll change. If nothing else, it would at least be a little more friendly. It is sad to see that you try to hide lack of DVD recording knowledge with false accusations and diversions. Cheers, Mario -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
On So, 18 Okt 2009, Joerg Schilling wrote: There is no need for a new implementation as there is a fast and and reliable OSS implementation that uses a license that is compatible with any other license. The point is that all the code should be clean and GPL without any special clauses as you tend to do. That simple. Now there is an implementation everyone can take without the need to quote anyone in the source code. Here we go. That is open source. And Thomas (a lot) and I (a bit) learned about funny algorithm and error correction. Not bad either. And the best of all, no need from you to answer on any announcement of Thomas with the same email you have taken bla bla bla. So there is also an advantage for you (aren't we nice to you!), you can stop writing these emails and concentrate on sueing other developers (as this is one of your hobbies). (BTW, you once threatend me to come over and find me, I am still waiting, shouldn't be tooo hard, and I am still not scared ;-) Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- Does it worry you that you don't talk any kind of sense? --- Douglas Adams, The Hitchhikers Guide to the Galaxy -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
People who read this list on a regular base know you from your rude attacks against other people bt definitely not from giving help. Yes, that's me! I am very scary ... :D - M. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
| From: Joerg Schilling joerg.schill...@fokus.fraunhofer.de | I am not shure whether you know that you are responding to a social problem. I certainly see a nasty tone on this message. I'm not going to judge who is right and who is wrong. This is a long conflict, as far as I know. My humble suggestion: everyone should tone the rhetoric. Surely all the points have already been made. Continued sniping reflects badly on everyone. As a user, I'm thankful for Joerg *and* everyone else who has helped to develop this code. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Mario Đanić wrote: The Problem is however, The problem is however that you are highly annoying. With the plans for libburnia website revamp, there is a plan to provide a replacement list for this list, where we would help any users, regardless of the software they use. Even if we have it now, its a bit under-promoted and has some spam. It'll change. If nothing else, it would at least be a little more friendly. This list is actually intended to be just that, and modulo Joerg's comments seems to serve well. It would really serve users better (if that's your intent) to continue on this list, and not force people to read yet another list to get information on all softwares. We have regular coverage of most of the popular burning programs, and some obscure software and questions in addition. Whatever you think of Joerg, he has contributed a number of useful solutions, and has maintained and improved his software for a decade. Anyone reading this list in historical context will know I'm not his fanboy (;-)), but I do use his software for a number of things. -- Bill Davidsen david...@tmr.com Unintended results are the well-earned reward for incompetence. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
D. Hugh Redelmeier wrote: | From: Joerg Schilling joerg.schill...@fokus.fraunhofer.de | I am not shure whether you know that you are responding to a social problem. I certainly see a nasty tone on this message. I'm not going to judge who is right and who is wrong. This is a long conflict, as far as I know. I suggested a few years ago that Joerg and his principal detractors go in a telephone booth and have a pissing contest, but I haven't seen it on youtube yet. I spite of the personalities users do get helped here, and seeing people make fools of themselves does have some amusement value. My humble suggestion: everyone should tone the rhetoric. Surely all the points have already been made. Continued sniping reflects badly on everyone. As a user, I'm thankful for Joerg *and* everyone else who has helped to develop this code. -- Bill Davidsen david...@tmr.com Unintended results are the well-earned reward for incompetence. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Announcing cdrskin-0.7.2
Hi, be invited to try the new version 0.7.2 of my program cdrskin, a burn backend for CD, DVD and BD with a command line interface compatible to cdrecord. System requirements: Linux with kernel 2.4 or 2.6: libc, libpthread or FreeBSD : libc, libpthread, ATAPI/CAM enabled, see atapicam(4) Changes: * Bug fix: CD TAO sessions with multiple tracks did not work in -dummy mode. * Now emulating option -minfo and printing those info lines which can be provided by libburn. * New info lines with -atip and -minfo: Product Id: provides a uniform single word for determining identity of media products. Line Producer: gives a guess about the manufacturer of the media. For more info, see http://scdbackup.sourceforge.net/cdrskin_eng.html http://scdbackup.sourceforge.net/man_1_cdrskin.html Download: There is a cdrskin release tarball (containing libburn): http://scdbackup.sourceforge.net/cdrskin-0.7.2.pl00.tar.gz scdbackup.sourceforge.net is mirrored at scdbackup.webframe.org . cdrskin is also part of the libburn-0.7.2 SVN tag: http://svn.libburnia-project.org/libburn/tags/ZeroSevenTwo (needs autotools = 1.7 to apply command ./bootstrap) and of the libburn-0.7.2 release tarball: http://files.libburnia-project.org/releases/libburn-0.7.2.pl00.tar.gz (needs only vanilla tools for ./configure ; make) Post bug reports or requests either to one of these mailing lists: mailto:libburn-hack...@pykix.org mailto:cdwrite@other.debian.org or directly to me: mailto:scdbac...@gmx.net Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Thomas Schmitt scdbac...@gmx.net wrote: be invited to try the new version 0.7.2 of my program cdrskin, a burn backend for CD, DVD and BD with a command line interface compatible to cdrecord. When will you correct your wrong claim that states you did not copy any byte from cdrecord's sources? Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Mario ??ani?? mario.da...@gmail.com wrote: Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. You discussed it with yourself. That's way different, don't you think? :) No, the announced code contains (different from that the project itself claims) code parts from an older version of the cdrtools source. Claiming that there was no such code move is a missinformation. Whether this has been done directly or indirectly does not matter as there are enough identifyable parts that have been written by Heiko Eißfeldt for cdrecord. The Copyright law requires to mention the original authors which is not done.. OpenSource gives many permissions but it does not allow to hide things. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
On Di, 13 Okt 2009, Joerg Schilling wrote: No, the announced code contains (different from that the project itself claims) code parts from an older version of the cdrtools source. Claiming that there was no such code move is a missinformation. Whether this has been done directly or indirectly does not matter as there are enough identifyable parts that have been written by Heiko Eißfeldt for cdrecord. The Copyright law requires to mention the original authors which is not done.. Shut up. We are all sick of that. Best wishes Norbert --- Dr. Norbert PreiningAssociate Professor JAIST Japan Advanced Institute of Science and Technology prein...@jaist.ac.jp Vienna University of Technology prein...@logic.at Debian Developer (Debian TeX Task Force)prein...@debian.org gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- POTT SHRIGLEY (n.) Dried remains of a week-old casserole, eaten when extremely drunk at two a.m. --- Douglas Adams, The Meaning of Liff -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, When will you correct your wrong claim that states you did not copy any byte from cdrecord's sources? The claim is uphold. Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. I removed the code which was labeled as stemming from cdrdao and was not used by tested parts of libburn anyway. It obviously implemented the Reed-Solomon error correction as described in ECMA-130. One thing is to understand the math behind Reed-Solomon, quite a different thing is to understand the discretization math which leads to the tables in the cdrdao implementation. Lacking the latter math i decided to give up the inherited but never working CD raw modes of libburn. http://libburnia-project.org/changeset/2779/libburn You were informed about that decision in http://lists.debian.org/cdwrite/2009/08/msg00021.html See last topic near end of message. You read and replied. libburn still does CD Mode 1 (-data) and CD-DA (-audio). It also does DVD and BD where i deliberately deviated from cdrecord's doings and rather followed the much more appealing example of growisofs. If you find any other code parts which appear copied from your projects then please report them explicitely. Our code is public and can easily be referred to. Most suspect would be CD SAO which is the last remaining write strategy that was not implemented by myself. - Dr. Norbert Preining Associate Professor JAIST Japan Advanced Institute of Science and Technology I google among other things: Institut für Diskrete Mathematik und Geometrie, Technische Universität Wien Do you know by chance a smart student who can contribute an implementation or explanation of ECMA-130 Annex A ? The RSPC is a product code over GF(28) producing P- and Q-parity bytes. The GF(28) field is generated by the primitive polynomial P(x) = x8 + x4 + x3 + x2 + 1 The primitive element a of GF(28) is a = (0010) where the right-most bit is the least significant bit. [...] The words RSPC and P- and Q-parity bytes belong to the CD sector format specs. But the others must be established mathematic terms. (How is this connected to a Fourier transformation of the bit sequence on time domain ? Urgh ! Analysis ! On a finite set !) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Thomas Schmitt scdbac...@gmx.net wrote: Hi, When will you correct your wrong claim that states you did not copy any byte from cdrecord's sources? The claim is uphold. Note that we did already discuss this some time ago and it is obvious that you _did_ copy sources from an older version. I removed the code which was labeled as stemming from cdrdao and was not used by tested parts of libburn anyway. It obviously implemented the Reed-Solomon error correction as described in ECMA-130. One thing is to understand the math behind Reed-Solomon, quite a different thing is to understand the discretization math which leads to the tables in the cdrdao implementation. Lacking the latter math i decided to give up the inherited but never working CD raw modes of Then please inform your users that you cannot grant correctly written CDs on Lite-ON drives and that you will not be able to write SVCDs on Pioneer drives. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, Then please inform your users that you cannot grant correctly written CDs on Lite-ON drives and libburn works fine with my olde LITE-ON LTR-48125S CD-RW burner. that you will not be able to write SVCDs on Pioneer drives. (Harrumph) Users ! You might not be able to write SVCDs on Pioneer drives ! (Good so ?) Users, please also note: I have no idea how to write SVCD on any drive. libburn does Mode 1 (-data) and Audio tracks. To mix them on the same media will possibly not work in your old CD player in the living room. If the player is actually a little computer then this ban on mixing will not be an issue. There are rumors that one would need Mode 2 for multi-session CDs. The only real hint for this are statements in ECMA-168 which have no influence on CD or on ISO 9660 (ECMA-119). The rumored prescription cannot apply to Audio as this is mutually exclusive with Mode 2. The rumored prescription cannot be essential with computer attached CD-ROM drives as i have a lot of experience with multi-session Mode 1 CDs meanwhile. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Hi, Bill Davidsen wrote: The usual programs to generate the info create multiple files and a cuefile (see the cdrecord man page). Real cdrecord uses this cuefile to write the SVCD media, It would be interesting to see the cuefile and a ls -l of the track source files. I will probably not be able to perform the necessary CD sector preparations by the current libburn. But it could give me an idea what sector formats are used. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
Re: Announcing cdrskin-0.7.2
Thomas Schmitt wrote: Hi, Then please inform your users that you cannot grant correctly written CDs on Lite-ON drives and libburn works fine with my olde LITE-ON LTR-48125S CD-RW burner. that you will not be able to write SVCDs on Pioneer drives. (Harrumph) Users ! You might not be able to write SVCDs on Pioneer drives ! (Good so ?) Users, please also note: I have no idea how to write SVCD on any drive. The usual programs to generate the info create multiple files and a cuefile (see the cdrecord man page). Real cdrecord uses this cuefile to write the SVCD media, the last (years ago) time I tried to do that with wodim it seemed to work but the media wouldn't play. This format is still (marginally) useful for small video where the quality of VCD is unacceptable and the cost between CD and DVD blanks matters. libburn does Mode 1 (-data) and Audio tracks. To mix them on the same media will possibly not work in your old CD player in the living room. If the player is actually a little computer then this ban on mixing will not be an issue. There are rumors that one would need Mode 2 for multi-session CDs. The only real hint for this are statements in ECMA-168 which have no influence on CD or on ISO 9660 (ECMA-119). The rumored prescription cannot apply to Audio as this is mutually exclusive with Mode 2. The rumored prescription cannot be essential with computer attached CD-ROM drives as i have a lot of experience with multi-session Mode 1 CDs meanwhile. Have a nice day :) Thomas -- Bill Davidsen david...@tmr.com Unintended results are the well-earned reward for incompetence. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@other.debian.org
