Brume's dumps

[dlfrsilver]

Yes, true original and the games were in mint condition. All other games I got from the seller were in perfect condition, I rarely find games in such condition. One question: when CTA detects modified tracks, does it also mean it can't generate IPF files?

Well most of the time it doesn't allow the generation, but on some games, it allows to, but a second copy is needed to check is it's the same or different.

PS : turrican I & II exists in multiple revisions. I have 2 differents dumps of my no-more-living disks of those games.

[AtariZoll]

1x512 + 1x128 + 5x1024
...WD1772 supports 128/256/512/1024 bytes/sect so I think it should be possible to copy these tracks with std Atari HW? In other word I do not see anything that WD1772 cant do?

The FDC can create and write that kind of sectors, but the ST can't write them at the necessary frequency to fit all of them on one track. You need a custom controller, or an FDC clocked faster, or a drive rotating slower.

Actually, in this case it is possible, I'm sure - since we have only 7 sectors on track instead 11 . So, less gaps. Basically, density is close to hyperformat. Of course, reliability will be lower, than by single pass write.
I saw something similar with Space Ace serial and Wrath of the Demon. In case of Space Ace there are 6x 1K sectors, but last is incomplete. Usable data length per track is 6048 bytes, and there is 2 byte special checksum at end of accessible area of 6th sector. That's certainly not possible to write with regular ST HW.

[ijor]

Actually, in this case it is possible, I'm sure - since we have only 7 sectors on track instead 11 . So, less gaps. Basically, density is close to hyperformat. Of course, reliability will be lower, than by single pass write.

You are right. It can fit using smaller gaps. But these disks were recorded at pretty high density. About 2.5% higher than nominal.

[ijor]

Seems like SPS people considers tracks with double sector splices as modified (as reported in CTA).

Are you sure? Doesn't sound too reasonable. If so how they detect modifications on raw tracks (without sectors) that will never have multiple write splices? Or for that matter, on Amiga disks that are always written in a single pass.

I find 2 sector splices (front of id and between id/data) for almost all sectors
...
Note that in many cases (like in Turrican) the detection of splices is not that easy. In many cases splices do not result in short/long fluxes but only in wrong sequence of bits. Therefore Aufit algorithm for splice detection uses three criterions ...

And what criteria you used here to determine those write splices in this case? I'm not sure these disks were recorded in two passes. Actually, these sectors don't look like were written by a WD1772 FDC.

[DrCoolZic]

This question should be asked to SPS people. I am sure of nothing concerning CTA.
In general I dont know how they detect modified track. But in this case it must be splice detection because I do not see any other reason?

I agree that it would be difficult to write this kind of track on an atari. Indeed the clock is about 2.5% above normal which seems to indicate usage of a specific hw (even though an approximate copy might be possible on atari).

Write splice detection is complex and still experimental in Aufit. You will find attached a preliminary description of the algorithm used.

Write Splices Information v1.0.rar

In Turrican there is no "out of band" transition. Therefore splices must be detected because of out-of-sequence transition (in Sequence of 00). But I would need to further investigate. These out-of-sequence transition may be placed on purpose (even though impossible to detect on atari?). Aufit does not provide bit level display the further I can go is at MFM level and I do not see an abnormal sequence at this level? It is also not displayed in disk view?

turrican no sector splice.PNG

Again in Aufit the splices detection just indicates that something abnormal has been detected in a gap field and nothing more.

[ijor]

Write splice detection is complex and still experimental in Aufit.

It is complex at the individual level. It is difficult to be sure in every single case if there is a write splice or not. But at the overall disk level, if the disk was written in one pass or two, it is almost obvious.

Therefore splices must be detected because of out-of-sequence transition (in Sequence of 00). But I would need to further investigate. These out-of-sequence transition may be placed on purpose (even though impossible to detect on atari?).

I doubt very much something like this was recorded on purpose. I think that for some reason you are detecting false positives.

[DrCoolZic]

Sorry my mistake

I have added many new features in Aufit around splices and as I have not used it for quite some times I did not remember that I turned on a flag that display start position of $00 sequence inside gap.

So Aufit does not detect any sector write splice (reason no black line in disk view) in this Turrican image it just provides indication about position of 00 sequence in gap!

So for Aufit this disk seems perfect only one track splice close to the index pulse. Therefore it is even more strange that CTA detect modified tracks?

[dlfrsilver]

Well, i know for a fact that duplication machines were writing gaps in a perfect manner, while computers FDC just can't do that.

The irregularities about GAPS can trigger the 'it's modified' when it's not.

When a computer saves or write on a duplicated disks, it's changing the gap sizes and positions. hence the detection of modified track.

In this respect, most spanish software are seen as copies, because they were using low grades duplicators (philips unix machines).

[JimDrew]

SCP's SPLICE mode locates an obvious write splice (which is really nothing more than at least one bitcell where its timing is much too long or much too short compared to the average bitcell times). Writing the track and the reading it back to look at what happened to the write splice that is deliberately being generated is how it basically works. Adjustments are made to the overall flux length to accommodate the particular drive's magnetic head collapse (smear). There are also some special cases to handle (strong bits and weak bits) too. When there is no obvious write splice, then any arbitrary bitcell can be selected as the stopping point. As long as the data looks identical after it is read, then it really doesn't matter. I do look for the flux abnormality first because it seems much easier to get this right the first time when calculating the drive speed vs. write splice smear.

[DrCoolZic]

Well, i know for a fact that duplication machines were writing gaps in a perfect manner, while computers FDC just can't do that.

The irregularities about GAPS can trigger the 'it's modified' when it's not.

When a computer saves or write on a duplicated disks, it's changing the gap sizes and positions. hence the detection of modified track.

In this respect, most spanish software are seen as copies, because they were using low grades duplicators (philips unix machines).

Contrary to what I said earlier the quality of the Turrican image is super hyper excellent!

If you look in disk view to track/sector beginning they all align perfectly. Even the track splice (in dark blue) due to out-of-band flux (in white) perfectly align. And I looked at the content of gaps at MFM level both with Aufit and CTA and they looks perfect. Therefore I so not know why CTA detects modified track?

turrican track splice.PNG

As a representative of SPS can you have a look at this image with CTA and let us know the reason of the modified detection.
Does the report "modified" in red means modified tracks? The CTA documentation indicates that "CTA does not support archival of modified disk". Therefore I should not have been able to save the IPF file?

Another interesting information about this image. Usually when a track has bit-width variation "all the bit-width are shifted". For example bit centered at 4,6,8 are shifted to 3.9, 5.85, 7.8 (2.5%). In case of this image look at Aufit histogram you will see that the bit-width are centered at 4 (not shifted), 5.75 and 7.82. Obviously this cannot be obtained on an Atari by varying the drive speed !!!

[DrCoolZic]

Note that CTA and Aufit have difficulties with the bith-width variation used in this disk. For many tracks CTA reports "unknown" and even "Noise" for density detection (even though they are correctly detected as MFM and not reported as noise in the "total"). While Aufit detects 4 long tracks.

[DrCoolZic]

Interesting!

I have decided to looked with CTA at the IPF file generated from ctr and guess what: we still have 151 modified tracks !?!
Here the modified detection is even more strange ?
Anybody tried the IPF file ?

We now have all tracks detected as "normal density", meaning auto width, meaning rotation time / divided by number of bits ...
Look at the perfect stable density graph
Probably close enough to original but different (remember the unusual dispersion of bit width)

[dlfrsilver]

Note that CTA and Aufit have difficulties with the bith-width variation used in this disk. For many tracks CTA reports "unknown" and even "Noise" for density detection (even though they are correctly detected as MFM and not reported as noise in the "total"). While Aufit detects 4 long tracks.

Hi jean, what you currently see inside the CTA view is not only the Density, but it also reflects the disc surface "quality".

when you have such a patchwork of colors, it means there is some dirtyness on the disk. For instance, my own CTRs of T1 and T2 from my original disks are cleaner than those of Brume.

basically, the two main colors are either Green (good and standard density), and red (long tracks or long track protection).

Note Jean : IPF made by us with CTA must not go public. They are temporary ones, and must only be delivered to the people uploading KFraw streams on the SPS FTP server.

other than that, the IPF you made works correctly, as much as the one i made from my own dumps.

[DrCoolZic]

Question when looking at CTA track density window there are two curves one in blue ans one in pink. The blue seems to be the bit-width what about the pink curve?

Not sure what yo mean by surface quality. Flux read by KF/SCP are "digitized" information. To me surface quality would be more at analog level that cant be accessed from std floppy drive? I certainly understand that image quality can be analyzed by looking at things like regularity of speed rotation, staart of track positioning etc. Again in case of the image provided by Brume it seems that it is an above average quality. If you have better quality image please publish them so we can compare. In this case I do not think that the "patchwork" of colors is due to surface quality but to the fact that all tracks use marginally high density (not enough to be detected as consistently long track) ...

As a company you probably do not want to infringe copyright law. therefore as I understand you do not publish KF and IPF files. I have uploaded KF files to SPS FTP server many many years ago but I never received any IPF files

A lot of people are now publishing KF/SCP/STX files so I feel like publishing IPF files is not different ... even though I understand you cant

Do you have an answer to why CTA detect "modified" track?

[Brume]

Note Jean : IPF made by us with CTA must not go public. They are temporary ones, and must only be delivered to the people uploading KFraw streams on the SPS FTP server.

Why the IPF generated by DrCoolZic should be considerated as a temporary file? What's the difference between this one and the one that could be generated by SPS team?
Btw, when someone uploads RAW files on SPS server, can't we named that a copyright infrigment, too?

[DrCoolZic]

Seems like SPS has a a double-face attitude. On one side they accept KF files from someone, and were supposed to provide in return an IPF file. As the person own the original, the IPF is just considered a backup and do not infringe copyright. But on the other side of course they keep a copy the KF and IPF files for preservation purpose which infringe the copyright because they do not own an original (personally I do not care!).
Unfortunately in my experience SPS is a black hole. As I said I provided KF files of many games but never got anything back in return? But I may be an exception?

Dfsilver can provided more detailed information but from what I understand only IPF files produced by SPS employee are considered as "certified". This is because SPS people are trained to produce IPF file. Therefore as I am an untrained user of CTA I can understand that they do not want to endorse IPF file produce by me (even if in most cases I am 99% sure of the produced file).

Note that each instance of CTA has an individual number associated. In my case the file produced by my CTA instance have creator id = $00001001
If you use my IPF reader you will find this information in the Info Record (third line of the dump)

[Brume]

That's very interesting, thank you for the information about SPS. So they can track an IPF generated by a user, right?

Also your return of experience doesn't encourage to share RAW dumps. Or maybe they lack staff? Anyway, that's why a RAW->IPF converter inside Aufit would be fantastic (don't want to insist but you know me)

What do you mean by "SPS people are trained to produce IPF file"? Do you mean they were trained in a camp, walking all the day and saying "one-two / one-two"? (just joking of course).

[DrCoolZic]

Producing IPF files is not too much difficult but producing correct IPF file is much harder

As Ijor mention here http://www.atari-forum.com/viewtopic.ph ... ad#p302749 verification and format are somewhat independent. It is just that IPF pushes you to perform complete verification/validation (I call that masterization or master template matching or ... ???) of the data.

Therefore the transformation of actual device dependent data to "master independent data" is the difficult part. But once done in Aufit it open the door to other possibilities. For example the Aufit input could be KF/STX but also CTR / STX and the output could be all the already available formats plus STX and SCP. This process transforms device dependent data to device independent (and therefore perfect) data similar to ctr to ipf transformation. So you would be able to take an STX file and produce a perfect floppy by writing IPF or SCP files.

Currently Aufit produces (probably like the pasti imager) "wrong" stx file that works. For example on a bad input images with large speed variation due to bad condition of the FD Aufit detects bit-width variation and produces stx file with timing records. During emulation this works perfectly because this information is just not used by the games but obviously unnecessary. During masterization it should be possible to detect and correct all these problems and produce perfect STX/IPF/SCT ... Note that currently Aufit already corrects several errors: for example if a dump is marginal and return good and bad sectors on several revolutions Aufit automatically select the good ones ...

[DrCoolZic]

That's very interesting, thank you for the information about SPS. So they can track an IPF generated by a user, right?

Yes anybody can check the creator id.

Also your return of experience doesn't encourage to share RAW dumps.

No I encourage people to share (even if it infringe copyright). But uploading to SPS FTP seems useless, apart from providing them information that they do not share for copyright reasons.

[dlfrsilver]

Double post by brume, look below

[dlfrsilver]

That's very interesting, thank you for the information about SPS. So they can track an IPF generated by a user, right?

Yes, all the IPF generated have an ID. An ID is equal to an identity (name and first name).

Also your return of experience doesn't encourage to share RAW dumps. Or maybe they lack staff? Anyway, that's why a RAW->IPF converter inside Aufit would be fantastic (don't want to insist but you know me)

Without analyse, those IPF are just copies.

What do you mean by "SPS people are trained to produce IPF file"? Do you mean they were trained in a camp, walking all the day and saying "one-two / one-two"? (just joking of course).

I have trained myself for quite a long time now to be able to make correct IPFs. This mainly because i have always been interested by copy protections since day one.

[Brume]

Copyright infrigement is based on possessing an original dump without having a proof that you own it. We don't deliver IPF to the public for this very reason. SPS is not a download plateform, and never was.

So when we send RAW dumps when you don't have the original software, you and the SPS team are violating the copyright, don't you?

You have no more excuse to say there's nobody to check your dumps, i'm here for that and for people asking to me since more than a year.

I let you answer

I wasn't looking for any excuse and I am not accountable to you... specially to someone like you who really hates Atari machines and their users

[dlfrsilver]

So when we send RAW dumps when you don't have the original software, you and the SPS team are violating the copyright, don't you?

Things are not working like that. I guess that my colleagues at SPS have of course foreseen all the possibilities regarding the law, and i think that the IPF creator, Istvan, has carefully verified what could be done or not.

He works in the industry, and as such can't be linked to copyright infrigement. He has bounds with people (i mean the video games creators), and those people are happy to get fresh masters of their games. This doesn't mean that they do agree for their IP to go for free.

So there are not infrigements at all.

I wasn't looking for any excuse and I am not accountable to you...

But that's what you implied by what you wrote basically. You came telling that no one replies when i PMed you eons ago about this matter.

specially to someone like you who really hates Atari machines and their users

You're entitled to have your very personal opinion. The fact is that i'm here as member on this forum since a long time ago now, i have hunted some of the ratest titles for Atari ST, i own myself ST machines, and what i think, my opinion should not upset you. Many people don't think the way i do, i'm not spending my time to hunt them and call them haters, or whatever words.

The true fact is that whatever my opinion, preservation is above everything to me.

And telling me i hate ST users is none sense. i don't know where you got this crazy idea. There are many great, nice and cool people in the ST communauty (Exxos for instance, Stefan, Kodak80, Maartau, etc etc, i won't list them all).

If i was thinking that the ST was that negligeable, i won't be preserving ST titles, and i would just not come here to post, chat, or whatever to anybody.

There are also great topics on St hardware, and i'm a big fan of that. So after this has been clarified, when do we start collaborating on ST games ?

I have already help tremendously Kodak80, he sent me many of his original games, and each time it was a winner, he got the corresponding IPF.

So what are you waiting for ?

[dlfrsilver]

The SPS moto has been like this since the beginning :

You as user owning an original is uploading your software in order to make it preserved. This constitute a proof for you as ownership.

SPS (we) are protecting ourselves from any lawyers attacks by showing "look for the game X, person Y has uploaded a dump (proof) against which we sent him an IPF.

That why SPS never gave publicly the IPFs made. It's up to the collectors to decide if they want to share or not what they got.

[AtariZoll]

Things are never good when someone or some group, institution claim exclusive rights about something. And that is what I see with SPS.
Above explanation of dlfrsilver makes no sense, but that's not "created" by him. For instance, legally it is not on "collector" to decide about sharing images of his originals. Could continue with arguments, but for sure nobody at SPS will not care. I had some mailing with Istvan Fabian (*in his mother language), and that was not pleasant. It is just ridiculous how they thread people - like judging validity of some image or converted image is some extra high science. I think that Atari community can get over it, and thanks to people working on diverse tools we will not need at all their "services".