Re: Announcing cdrskin-0.7.2
| From: Thomas Schmitt | A new source module ecma130ab was committed | to libburn SVN yesterday. Sounds good. | I would appreciate if you had a look at the | explanations at lines 8 to 115 whether you find | any mistakes or gaps. | http://libburnia-project.org/browser/libburn/trunk/libburn/ecma130ab.c I'm not really qualified to do a good audit. And I was too lazy to chase down all references. From what I could tell, it looked good. I don't understand the multiplication by logarithms (again, I haven't looked it up). Why are the two logs added as integers (+) rather than as polynumials (^)? Why do you do % 255 rather than 256? Note that the gfpow table has 256 entries. I do know that 0 has no log. If you double the gfpow table's size you could elminate the % 255. I would guess that this would increase the speed. I don't know if multiplication takes a significant percentage of the time. (I ran out of time after reading the first function!) Does ECMA provide any "test vectors" for you to test your code with? Unit tests might be very useful! -- 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 | 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 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
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 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
| From: Joerg Schilling | 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: My Pioneer DVR-218L i think is behaving like the "LG GH20NS10 might hang at the end of DVD-R[W] DAO recording..."
> I recently purchased a Pioneer DVR-218L SATA dvd recorder, to replace an > old IDE Pioneer recorder. > The unit works correctly when burning data, and it works correctly under > Windows. But when i tried to burn a Video-DVD under Linux (K3B), it gave > me an error in the very end of the recording process. I searched for > information, and after a while, I found this: > http://www.mail-archive.com/cdwrite@other.debian.org/msg12340.html > > That thread describes my situation almost exactly, except I own a > Pioneer, not LG drive. > > Here are a couple of debug logs of K3B when failing: > http://pastebin.com/f416c99d2 Yes, it appears as similar problem, i.e. recording size is not divisible by 32KB, it's DAO recording and the last write appears timing out. Can you verify if workaround at the end of http://www.mail-archive.com/cdwrite@other.debian.org/msg12357.html helps in your case too? As far as I understand K3b offers DAO as GUI check-box, so you can as well let it be in order to make it work with your unit. > Here is the output of > dvd+rw-mediainfo /dev/scd1 > INQUIRY:[PIONEER ][DVD-RW DVR-218L][1.01] > Complete here -> http://pastebin.com/f9309400 (with the data of the > Verbatim 16X DVD-Rs I used to burn) It's of greater relevance/interest to look at dvd+rw-mediainfo for *resulting* recording, not for blank media. There you should be able to confirm that READ CAPACITY and/or lead-out position are adequate, recording size / 2048 to be specific. Thanks for submission. A. -- To UNSUBSCRIBE, email to cdwrite-requ...@other.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@other.debian.org
Re: solaris cdrecord BH08LS20 drive BD-R problems
>>> If you like to prove that there >>> are Sparc machines with Solaris that behave different from what all other >>> users >>> reported, please send the related information: >>> >>> - exactly describe the machine type, the OS release and the drive type. >> Information can be found in attachments. > > Looking through the information does unfortunately not show anything that > verifies the presence of DMA for the CD-ROM drive in question. Looking through the *requested* information does not show anything that verifies the presence *or absence* of DMA for the CD-ROM drive in question. SPARC Solaris does not tell a squat about DMA settings in /vad/adm/messages, 'eeprom' or 'prtconf -p' outputs. On the other hand, looking through the information provided *beyond* requested one allows to draw conclusion that DMA is *in fact* enabled for optical drive in question. Once again, target1-dcd-options is 0xa2 and more important read performance reaches 19MBps[!]. Indeed, there is no way venerable Blade-100 can deliver that much over PIO at *portion* of CPU power(*). As for value of 0xa2. Earlier I said that it denotes UDMA-2. As it turns out this was inaccurate. Upper bits, ones constituting 0xa?, do denote UDMA, but lower bits, ones constituting 0x?2, don't denote UDMA *mode*. Lower bits are meaningful when UDMA is disengaged and seem to denote PIO mode. In other words, while not being specific about UDMA mode, the value still tells that UDMA is actually enabled. (*) Well, patching uata driver to avoid DMA in atapi_ routines have shown that same experiment, pread(2) with fixed offset in loop, delivers not more than 2.7MBps at 95% of CPU time! Even though above is about SPARC Solaris 8 I found no evidence that DMA default settings for ATA would be different on SPARC Solaris 10 and even OpenSolaris for SPARC. Unfortunately I have no opportunity to confirm this experimentally. The conclusion is based on once observed target?-dcd-options value on SPARC Solaris 10, comparison of binary code for uata driver in all three releases, and on comparison of source code for Solaris 8 and OpenSolaris. All this naturally doesn't mean that all versions of SPARC Solaris *unconditionally* use DMA with ATAPI, but it's enough to conclude that originating "Solaris sparc still does not support DMA on ATA interfaces" is not justifiable. In the course of discussion it was also implied that cdrecord's "Solaris DMA related READMEs" are up-to-date with accuracy of 12 months and apply to *all* Solaris releases. To summarize, the READMEs discuss binary patching of ata binary driver on Solaris 9 x86 as the only way to engage DMA for optical ATAPI units. I don't recall when Solaris 10 was released, but from my >4 years personal experience with Solaris 10 x86 on Sun W1100z (Opteron-based workstation), it's perfectly possible to control DMA setting for optical ATAPI unit with atapi-cd-dma-enabled boot parameter and no binary patching is required. This applies even to OpenSolaris for x86 (where it's even properly documented in ata(7d)). Then there is enough evidence that the READMEs in question are not applicable to [any recent] SPARC Solaris release. At the very least on SPARC Solaris ATA is implemented by uata driver, which does not even have ata_init_drive_pcidma subroutine. Not to mention above information about DMA *defaults* for SPARC Solaris ATA support. A. -- 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
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. I am not convinced that you are interested in giving people help and I am not even convinced that you could give them help. People who read this list on a regular base know you from your rude attacks against other people bt definitely not from giving help. > It is sad to see that you try to hide lack of DVD recording knowledge > with false accusations and diversions. See above and BTW: Cdrecord supports to write DVDs since February 1998. Guess who did write the related cocde? 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 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
> 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
"D. Hugh Redelmeier" wrote: > 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 I am not shure whether you know that you are responding to a social problem. 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 Problem is however, that Thomas is not willing to name the fact that he did take an implementation from someone else and that he is not willing to name the author (Heiko Eißfeldt) of this implementation. Heiko did make the first publically available implementation of a CD raw sector encoder 10 years ago and this did take a lot of time using the public information from 1999. Heiko did not only implement an encoder but also a "decoder" (a piece of software that corrects read errors from data with Reed Solomon FEC). Both libraries are available for anyone as part of the cdrtools project. Thomas before did take an old implementation from the same author that was not made available under a OSS license instead of taking a recent version that is under a OSS license that is compatible with any other OSS project and that is even aprox. 10x faster than the old implementation. I am not sure about the background for his behavior.. 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, > it seems as if the > internet has enough information to get to a solution. Yes, it has. A new source module ecma130ab was committed to libburn SVN yesterday. I would appreciate if you had a look at the explanations at lines 8 to 115 whether you find any mistakes or gaps. http://libburnia-project.org/browser/libburn/trunk/libburn/ecma130ab.c By help of Norbert Preining i found a document about Reed-Solomon for RAID applications by James S. Plank which provided me with the theoretical background to understand ECMA-130 Annex A. The resulting implementation is unoptimized and needs about 50 % more time than the old one which was labeled "borrowed HEAVILY from cdrdao". ECMA-130 Annex B, the scrambler, was easier to learn. Only obstacle was that the diagram in ECMA-130 shows a 16 bit register in Fibonacci form whereas the text talks of a 15 bit register with a 15 bit polynomial that refers to the Galois form. Well, if one removes the surplus box from the Fibonacci then it is trivial to implement. (Thanks to a company named New Wave Instruments for an overview of Linear Feedback Shift Register nomenclature.) I ran my whole hard disk content through a comparison of old and new output. It matched. Whether the old output exactly complies to ECMA-130 would be subject to a real test case for raw CD writing. I learned that Annex A is needed to encode a data block into an audio-sized sector. Annex B is needed to prepare an audio-sized sector for raw writing. Both tasks are performed by the drive if the MMC defined write modes for data and audio are used. > Gallois Fields have size p^m where p is a prime (in our case, 2). ... and weird arithmentics (at least with p=2). Plus is minus, logarithms are exact, powers of x behave like elements of modulo prime groups. (I seem to have backed out of algebra just before finite fields became topic.) > I admit that I'm shooting from the hip here. Good shot. The only thing that i have to amend is that the road via Fourier turned out to be a diversion. All statements in ECMA-130 Annex A refer already to the finite field aspect of Reed-Solomon. (I did not have to learn how frequencies and finite fields are related. It has to be expected that there is funny arithmetics, too.) 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
