[kaikow]

My recollection is that Vista was supposed to include native packet writing software. Does it?

If so, is Drag 2 Disc even needed under Vista?

[james_hardin]

kaikow, on Nov 26 2006, 12:30 PM, said:

My recollection is that Vista was supposed to include native packet writing software. Does it?

If so, is Drag 2 Disc even needed under Vista?

Hard to say what will make the final cut…

CD burning is included in XP, does that mean no one ever need install Roxio?

It will prove interesting, after Vista is actually released. Packet Writing has proven itself to be the most unreliable form of burning ever devised.

Why would one expect an MS version of it to be any better?

MS brought us QuickFormat some years ago. Now you would be hard pressed to even find a burner that supports it!

MS brought us Y2K…

Just going to have to wait and see.

[Beerman]

kaikow, on Nov 26 2006, 11:30 AM, said:

My recollection is that Vista was supposed to include native packet writing software. Does it?

If so, is Drag 2 Disc even needed under Vista?

I have the Vista Ultimate (RTM) and Vista does indeed contain support for the UDF file system. I'm having trouble with using CD's but DVD's appear to work fine. I don't use this anyway and you're correct that it's unreliable.

[kaikow]

Beerman, on Nov 26 2006, 05:52 PM, said:

I have the Vista Ultimate (RTM) and Vista does indeed contain support for the UDF file system. I'm having trouble with using CD's but DVD's appear to work fine. I don't use this anyway and you're correct that it's unreliable.

THe manual states:

Quote

Note Drag-to-Disc does not run on Windows 2000. Vista
compatibility is based on the pre-release versions of the software
available at the time of Easy Media Creator 9 release. Some
applications may require an update for full compatibility.

I am guessing that "Windows 2000" should have been "Windows Vista".

And packet writing is not at all unreliable, it is the incompetent implementations that have made it appear so,

FYI, I was one of the architects of ISO/IEC 13336, on which the UDF spec is based.
The problem is not packet-writing, that's straightforward.
The implementations are just bad and/or incompatible.

See more and yet more.

[grandpabruce]

kaikow, on Nov 26 2006, 12:04 PM, said:

And packet writing is not at all unreliable, it is the incompetent implementations that have made it appear so,

FYI, I was one of the architects of ISO/IEC 13336, on which the UDF spec is based.
The problem is not packet-writing, that's straightforward.
The implementations are just bad and/or incompatible.

You go ahead and keep convincing yourself of that.

[james_hardin]

Howard: I do appreciate your work on these standards.

While the packet writing standards may be flawless, it is disappointing that no one has ever been able to write an application that doesn't suddenly leave a user with an unreadable disc. It doesn't happen all the time but it happens with enough frequency to dissuade most users from using it. I am one of the few who do use it from time to time and my records indicate failures occur around the 50 uses mark. You can blame the media, I do, but the point remains, this doesn't happen with data projects or session writing.

This is why I am curious to see what will happen with Vista if packet writing becomes more widespread…

Don't have W2K but I believe the documentation is correct in that D2D will not install on a W2K machine. Could be it requires a UDF reader and W2K lacks that, whereas XP and Vista will have one.

There have been some changes in D2D V9. UDF 2.0 being the default file system. Also all media formatted prior to V9 is not writable with V9. It is also giving users fits even reading older media. But V9 formatted media is writable back to V6. (I haven't taken one to work yet to try it on a PC there with DirectCD from V5.)

Should be interesting to watch…

[Stas]

kaikow, on Nov 26 2006, 10:04 AM, said:

The problem is not packet-writing, that's straightforward.
The implementations are just bad and/or incompatible.

This is what I was also saying here:

http://forums.support.roxio.com/index.php?...amp;#entry64753

And burning software included in Vista was actually developed by Sonic/Roxio according to this press release:

http://www.sonic.com...6/10/vista.aspx

And given how good it is in Vista in terms of reliability and compatibility I just cannot understand why they couldn't do the same with Drag-To-Disc included in EMC9.

Whatever some people say, packet writing is very useful functionality. Of course you will not use it for permanent writings to write-once discs like DVD+/-R, but for +/-RW discs where your data change incrementally I do not see anything wrong in using it.

[james_hardin]

Stas, on Nov 27 2006, 03:20 AM, said:

This is what I was also saying here:

http://forums.support.roxio.com/index.php?...amp;#entry64753

And burning software included in Vista was actually developed by Sonic/Roxio according to this press release:

http://www.sonic.com...6/10/vista.aspx

And given how good it is in Vista in terms of reliability and compatibility I just cannot understand why they couldn't do the same with Drag-To-Disc included in EMC9.

Whatever some people say, packet writing is very useful functionality. Of course you will not use it for permanent writings to write-once discs like DVD+/-R, but for +/-RW discs where your data change incrementally I do not see anything wrong in using it.

Stas: There is absolutely nothing in the sonic.com link you provided that states or implies that packet writing or D2D is being licensed to MS… If I missed it, please point it out.

While I suspect this is true, there is no evidence provided.

Likewise, since Vista has yet to be released, I don't see how one can project its' "…terms of reliability and compatibility…"?

If it is as reliable as you allude, then why are you not using it for your own "…permanent writings…"?

It does work with R media so I really cannot understand how one would flaunt it but not use it…

[kaikow]

grandpabruce, on Nov 26 2006, 06:10 PM, said:

You go ahead and keep convincing yourself of that. ;)

Implementations are the problem, just as inept implementations were the problem in the early years of ISO 9660.
I'll respond further in another reply.

[kaikow]

james_hardin, on Nov 26 2006, 10:54 PM, said:

Howard: I do appreciate your work on these standards.

While the packet writing standards may be flawless, i

The problem is not the packet-writing standards, the problems are:

1. Implementors do not know how to read/use a standard. Similar problems occurred in early teats of ISO 9660. Indeed, some well known implemmentations INTENTIONALLY improperly implemented ISO 9560.

2. ISO/IEC 13346, on which UDF was based, had many errors, technical and otherwise, when it was first published. I will not go into the diry laundry that caused this, but I will state that the standards process has great flaws that permit technically incorrect standards (with known problems) to be published. These errors have exacerbated the issue.

Heck, back when ISO 9660 was first published (April 1988), ISO made a gross typesetting error. I was able to convince them to fix this, resulting in the September 1988 re-release of ISO 9660 The re-lease include several fixes that I made, but ISO would NOT allow me to make one more editing pass, so ISO 9660 is also not error free. But, ISO 9660, the error(s) have obvious solutions, and the format is a lot less complex than ISO/IEC 13346. so we have overcome the problems.

The problem is not with the packet-writing, tho I guess there is firmware that screws that up, the problem is the improper implementation of the volume and file structure.

This post has been edited by kaikow: 27 November 2006 - 06:43 AM

[The Highlander]

kaikow, on Nov 28 2006, 03:42 AM, said:

The problem is not the packet-writing standards, the problems are:

1. Implementors do not know how to read/use a standard. Similar problems occurred in early teats of ISO 9660. Indeed, some well known implemmentations INTENTIONALLY improperly implemented ISO 9560.

2. ISO/IEC 13346, on which UDF was based, had many errors, technical and otherwise, when it was first published. I will not go into the diry laundry that caused this, but I will state that the standards process has great flaws that permit technically incorrect standards (with known problems) to be published. These errors have exacerbated the issue.

Heck, back when ISO 9660 was first published (April 1988), ISO made a gross typesetting error. I was able to convince them to fix this, resulting in the September 1988 re-release of ISO 9660 The re-lease include several fixes that I made, but ISO would NOT allow me to make one more editing pass, so ISO 9660 is also not error free. But, ISO 9660, the error(s) have obvious solutions, and the format is a lot less complex than ISO/IEC 13346. so we have overcome the problems.

The problem is not with the packet-writing, tho I guess there is firmware that screws that up, the problem is the improper implementation of the volume and file structure.

I think you will find no one argueing with you over standards and ISO 9660 ect ect bla bla,
I think you need to re-read James comments on why WE don't use it or why WE do use it...
other wise go ahead and do what you think is right...

[Stas]

james_hardin, on Nov 27 2006, 05:51 AM, said:

Stas: There is absolutely nothing in the sonic.com link you provided that states or implies that packet writing or D2D is being licensed to MS… If I missed it, please point it out.

While I suspect this is true, there is no evidence provided.

Likewise, since Vista has yet to be released, I don't see how one can project its' "…terms of reliability and compatibility…"?

If it is as reliable as you allude, then why are you not using it for your own "…permanent writings…"?

It does work with R media so I really cannot understand how one would flaunt it but not use it…

Hi James,

Well, the Sonic's article is written for non-technical public, so it does not explicitly mention "packet writing" because no one would understand what it means. So while statements like "The built-in AuthorScript engine provides features within Windows Vista that help users archive digital memories to CDs and DVDs, create custom music discs, and perform important data backup functions." is pure marketing, the title of that article, which is "Sonic Provides Burning Engine in Windows Vista", says everything.

I do not use packet writing for permanent recordings to +/-R discs because it is inpractical to use it in this case. Normal session-based writing is more suitable here. It should also be faster, because from my understanding of how it works in case of packet writing the recording program has to constantly check what's going on on the disc during writing, while in case of session-based writing it just writes an "image" which it creates in its "head" prior to writing. So while packet writing is more sophisticated technique, its use for +/-R discs creates unnecessary overhead without giving any advantage.

But I also see it absolutely inpractical to use session based writing in cases where I use packet writing. Suppose you have a folder, say "My Documents" which constantly changes. I add, edit and delete files there every day. I would like to have a disc with the content of that folder for two purposes: 1) Just to keep another backup copy of files. 2) To be able to work with files on my home laptop. So, according to those who hates packet writing, should I re-backup the whole content of "My Documents" at the end of a working day just because I added one file, deleted another and changed yet another? Is this what you are suggesting to do? No way!

But my main point is that even if we assume that you are right that packet writing technology is more prone to sudden errors because of it's complexity, most problems (99.9%) which people experience with packet writing software currently on the market are not due to issues inherent to packet writing, but due to trivial bugs in software and development decisions made. It is not inherent packet writing problem, that Drag-To-Disc 9 causes "Blue Screen" every now and then, nor is the fact that it was made incompatible with discs created by previous versions. Or that Nero InCD was putting current dates for copied files in four consecutive versions of the software from the end of June to the end of November (they finally fixed this bug in Nero 7.5.9.0).

So if the implementation of packet writing in Vista proves to be good, the packet writing technology will finally wash away the stain of irreliability, which was put on it by negligent developers of current software.

Regards,
Stas

This post has been edited by Stas: 28 November 2006 - 03:14 AM

[ggrussell]

Stas, on Nov 28 2006, 05:37 AM, said:

...should I re-backup the whole content of "My Documents" at the end of a working day just because I added one file, deleted another and changed yet another? Is this what you are suggesting to do? No way!

Any GOOD backup software should have an option to only back up 'changed' files. I backup my data files to an external hard drive using software that does a simple file copy. I can plug my external backup drive into ANY computer and start to use the files without any special software to access them.

[james_hardin]

Stas: Please understand that this is a discussion and I am not trying to fight with you.

Regarding Sonic's release. It is not subject to between the lines interpretation. It says what it says and nothing beyond that!

Paraphrasing your long response, with some creative exaggeration:

Packet writing is 100% reliable but all the software writers in the world are too stupid to get it right!

While urging others to use it or at least chastising those who knock it, you won't use it yourself for backups.

A Blue Screen with D2D? It has been running 24/7 for over 4 months on my PC. I have yet to see that happen.

You do realize that the developers who are supplying MS with packet writing are same negligent developers who wrote DLA and D2D???

This post has been edited by james_hardin: 28 November 2006 - 08:30 AM

[kaikow]

james_hardin, on Nov 28 2006, 04:28 PM, said:

Packet writing is 100% reliable but all the software writers in the world are too stupid to get it right!

In a few cases, stupidity might be the problem, the real problems are:

1. The educational system has failed to teach folkes HOW to OBJECTIVELY read, be it a standard, or any other document.

2. Few of those folkes claining to be able to read objectively actually can.

3. When a standard has an ambiguity, or eror, few even know how to go about getting a proper interpretation from the relevant standards folkes. Even then, there can be problems due to the stupidity of folkes.

A well known case was many years ago.
In the USA, there is/was a COBOL validation test administered by an agency of the US gummermint.
A validation test can address ambiguities in ONLY two ways:

a. Omit testing the feature.
b. Test the alternatives, just to report the result, but do not fail a product based on the tests.

Well, in the case of the COBOL standard, there was a wll-known ambiguity. The COBOL standards committee had agreed on a clarificationfor the next version of the standard, butt, and I use butt here intentionmally, the guy in chrge of thevalidation tests decided to use his own interpretation. Talk about abuse of power!

Since products had to pass the COBOL validation to sell to the gummermint, and even to some private organizations, implementations were forced to implement according to this single individual's interpretation.

When I asked a particular COBOL developer why he had implemented according to the COBOL committee's interpretation, he said "Because I felt like it".

4. Few folkes even know whoto contact to get proper interpretations of a standard. And even when they do, they still screw up.

For example, 20 years ago, or so, a number of major vendors called me to ask about particular features of ISO 9660. In one case, Ihad a lengthy discussion explaing something that was clear in the standard, but the guy still implemented it incorrectly. About a year later, another individual had taken over the project, and called me to confirm that the other guy had done it wrong. I ASSuME that the implementation was corrected.

Ah shucks, I can go on and on, but I'm done!
Other than finding out whether Drag 2 Disc is necessary in Vista, there's no point in discussing this other stuff.

[Stas]

ggrussell, on Nov 28 2006, 06:44 AM, said:

Any GOOD backup software should have an option to only back up 'changed' files. I backup my data files to an external hard drive using software that does a simple file copy. I can plug my external backup drive into ANY computer and start to use the files without any special software to access them.

I't all clear with hard drives and flash. But we are discussing optical discs here. And to make a backup of only changed files to an optical disc using any "good backup software" you need a UDF-formatted disc and packet writing software installed on computer.

I just wrote this, but now I think that this only applies to backup software which makes backup by maintaining an exact copy of files and folders on destination drive / disc. The backup software I encountered with usually creates some kind of archives every time it backs up something and I now think that with this type of software session based recording can indeed be used...

But actually I don't use any backup sotware at all. Whether I back up to an external hard drive or UDF formatted DVDs, I just copy folders which I want to back up to the destination drive / disc as they are and later use folder comparison software which reports differencies between folders and then manually synchronise folders using Windows Explorer.

[Stas]

james_hardin, on Nov 28 2006, 08:28 AM, said:

A Blue Screen with D2D? It has been running 24/7 for over 4 months on my PC. I have yet to see that happen.

You do realize that the developers who are supplying MS with packet writing are same negligent developers who wrote DLA and D2D???

Hi James,

You are lucky you are not getting Blue Screen while working with D2D. I do get it quite often. And other people were posting same problem to this forum as well. Just two days ago I had to format another disc and fill it with data. I had three blue screens before I finally wrote all the data. Actualy I almost got used to it. It doesn't seem to break any files which are already there, only the last bunch of data which are being copied when this happens gets lost. So I have to copy again.

I uninstalled all the programs which I thought might have interfered with D2D, like VirtualCloneDrive, AnyDVD, even iTunes (it has some GEAR driver related to CD/DVD). Not just uninstalled, but examined whether some driver files left and deleted those which left. Also updated video driver (because once Microsoft report told me that the driver caused the crash was video driver, all the other times it was saying 'unknown device driver'). Nothing helped.

I have the same problem on my laptop. It has completely different hardware, also different drive manufacturer. Software installed is similar though. So I think it is purely software problem. Actually I think it is D2D 9 problem, because this only happens when it copies files and it was not happening with previous version of it.

I can send you records from the event log and dumps created by Windows if you are interested.

> You do realize that the developers who are supplying MS with packet writing are same negligent developers who wrote DLA and D2D???

As to this, I hope Microsoft has better quality control and that they thoroughly tested and maybe even reviewed the source code of that Sonic's "Burning Engine" before they let it be shipped with Vista. So they negated the effect of those "negligent developers". I might be wrong, but this is just my first impression: burning in Vista works properly, while burning in EMC9 doesn't. Well, it works somehow. But not as it should.

This post has been edited by Stas: 29 November 2006 - 02:04 AM

[james_hardin]

Howard & Stas: I want to thank both of you as I have learned a lot in a couple of days.

You are probably correct that MS will force stability into packet writing. Perhaps this will bring packet writing into the forefront of burning options.

[lynn98109]

james_hardin, on Nov 29 2006, 03:41 AM, said:

Howard & Stas: I want to thank both of you as I have learned a lot in a couple of days.

You are probably correct that MS will force stability into packet writing. Perhaps this will bring packet writing into the forefront of burning options.

My software guru earlier said that the reason the CD burning on WinXP is Sessions rather than Packet-Writing is because Microsoft didn't want to deal with the problems that come with Packet-Writing.

We shall see.

Lynn

[John at Roxio]

Stas, on Nov 29 2006, 03:02 AM, said:

Hi James,

You are lucky you are not getting Blue Screen while working with D2D. I do get it quite often. And other people were posting same problem to this forum as well. Just two days ago I had to format another disc and fill it with data. I had three blue screens before I finally wrote all the data. Actualy I almost got used to it. It doesn't seem to break any files which are already there, only the last bunch of data which are being copied when this happens gets lost. So I have to copy again.

I uninstalled all the programs which I thought might have interfered with D2D, like VirtualCloneDrive, AnyDVD, even iTunes (it has some GEAR driver related to CD/DVD). Not just uninstalled, but examined whether some driver files left and deleted those which left. Also updated video driver (because once Microsoft report told me that the driver caused the crash was video driver, all the other times it was saying 'unknown device driver'). Nothing helped.

I have the same problem on my laptop. It has completely different hardware, also different drive manufacturer. Software installed is similar though. So I think it is purely software problem. Actually I think it is D2D 9 problem, because this only happens when it copies files and it was not happening with previous version of it.

I can send you records from the event log and dumps created by Windows if you are interested.

> You do realize that the developers who are supplying MS with packet writing are same negligent developers who wrote DLA and D2D???

As to this, I hope Microsoft has better quality control and that they thoroughly tested and maybe even reviewed the source code of that Sonic's "Burning Engine" before they let it be shipped with Vista. So they negated the effect of those "negligent developers". I might be wrong, but this is just my first impression: burning in Vista works properly, while burning in EMC9 doesn't. Well, it works somehow. But not as it should.

In this particular case, you may want to just contact our support department directly.