Is it possible to convert between dump styles?

From what I've loosely understood is that non-null data is the same. The difference arises from Redump having null data prefixed or appended, and index entries adjusted appropriately.

If this is indeed the case I can probably write an AutoIt script to make the proper adjustments to convert Tosec to Redump...and ideally vise versa.

The idea of course is to get both groups efforts completed as soon as possible...and to reduce duplication of effort.

So if this is possible what are the test conditions?

Example:
<Track 1 Data> = 00:00:00
-- If Track 1 End Point Does Not Equal Track 2 Start Point Then Prefix Null To Track 2 & Adjust Track 2 Start Point
<Track 2 Audio>
<Track 3 Data> = 10:00:00
-- If Track 3 End Point Does Not Equal Track 4 Start Point Then Prefix Null To Track 4 & Adjust Track 4 Start Point
<Track 4 Audio>
-- If Track 5 Is Audio Then If Track 4 End Point Does Not Equal Track 5 Start Point Then Prefix Null To Track 5 & Adjust Track 5 Start Point
-- If Track 5 Is Data Then If Track 4 End Point Does Not Equal Track 5 Start Point Then Append Null To Track 4
<Track 5 Audio>
-- If Track 6 Is Audio Then If Track 5 End Point Does Not Equal Track 6 Start Point Then Prefix Null To Track 6 & Adjust Track 6 Start Point
-- If Track 6 Is Data Then If Track 4 End Point Does Not Equal Track 6 Start Point Then Append Null To Track 5
<Track 6 Data>
....

Is that the correct conditions or is it different?

http://forum.redump.org/topic/6142/tosec-dumps/

plz search  smile

Yeah I found that, however I found posts also stating that there was some bs data showing up in the gaps as well...that you guys are trying to grab...at least according to that post.

I guess I should be more to the point...If I did create converted dumps would they be accepted? I know well enough how to do things...just trying to avoid some trial and error...and ultimately possible rejection.

Nologic wrote:

I guess I should be more to the point...If I did create converted dumps would they be accepted? I know well enough how to do things...just trying to avoid some trial and error...and ultimately possible rejection.

I was afraid that question would come one day.
Accepted in what way? To be added to the base? NO!!!

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Thats odd since from what I read here on the forums at least one person has dumped a DC game with httpd-ack and null padded it...which appears from the forum post to have been accepted.

Yet when I purpose the same thing only automated...I get told no harshly.

Ether that method is acceptable or not.

Further both Redump and Tosec put this information and binaries out in public...so exactly whats wrong with using this stuff? Less it's simply a matter of ego...which really is the only way I see this.

Question if I convert Redump DC over to Tosec DC and find the match's are you guys going to pull those from the database?

Hell nether you guys or Tosec are interested in actually getting shit done...I got like 30 new dumps sitting over there and not a pip out of anyone.

Why the hell should anyone bother giving aid to you guys or tosec?

Nologic wrote:

from what I read here on the forums at least one person has dumped a DC game with httpd-ack and null padded it

Linky please?

Nologic wrote:

Further both Redump and Tosec put this information and binaries out in public...so exactly whats wrong with using this stuff? Less it's simply a matter of ego...which really is the only way I see this.

Both dumping methods are to different, no serious group will accept converted data therefore.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

Nologic wrote:

Thats odd since from what I read here on the forums at least one person has dumped a DC game with httpd-ack and null padded it...which appears from the forum post to have been accepted.

Yet when I purpose the same thing only automated...I get told no harshly.

Ether that method is acceptable or not.

Further both Redump and Tosec put this information and binaries out in public...so exactly whats wrong with using this stuff? Less it's simply a matter of ego...which really is the only way I see this.

Question if I convert Redump DC over to Tosec DC and find the match's are you guys going to pull those from the database?

Hell nether you guys or Tosec are interested in actually getting shit done...I got like 30 new dumps sitting over there and not a pip out of anyone.

Why the hell should anyone bother giving aid to you guys or tosec?


we actually care for quality and real 1:1 hashdata

@ iR0b0t -

I believe this is the thread I originally referred too.
[Linky]

hmm both groups are dumping 2352 sectors...the only visible difference is the gap data...which is typically all null. Further its...well track gaps...I mean what the hell.

@ GBK666 -

Yeah those few random useless symbols out in the middle of nowhere, that are not read by consoles or emulators are oh so important.

Minus the gap data of Redump, they will return the same SHA-1 values if the games are the same batch.

Puff your chest out over the track gaps if you like...but in reality its useless...and frankly a waste of time grabbing them.

Having a preference to having the gaps represented far as layout...fine...but actually dependent on them...is frankly silly.

I see no reason or sense in wasting peoples time, effort and money over junk data that is not used EVER.

I mean it makes as much sense as demanding the chemical makeup of the shrink-wrap that the game originally came in...it's useless and not necessary.

it's quite useless for emulation, yes. but it's necessary to organize good db (i.e. preservation project).

gaps is one thing, another thing with TOSEC is that they do not cancel CD offset. this shifts all audio data in one direction or other relative to data tracks. some of audio data often enough is shifted out of dumped range - if it ends up in gap or lead-out - then it's cut off and lost.

so TOSEC dumps depend from offset of master (there often are several); single game made from masters with different offsets will have different entries, when actually it's same CD. instead of verifying one another, those entries create clones (also no relation among audio data from different regions, or consoles, since usually those would have different offsets too). and since audio data can be cut off, they can end up with several clones none of them covering whole audio data, so no matter how you shift this data afterwards, it won't fully match to that from another entry.

specifically for DC they do not cancel drive offset too, which they assumed was always the same for this console, but as it later turned out - it isn't - yielding more problems.

the devil is in the details.

lol this topic starts to remind me that dude Eidolon.
http://forum.redump.org/topic/2387/rela … -tosecorg/

Anyway Nologic, the methods described here can be pain in the ass sometimes but they exist for a reason. You either accept them or not. If something changes (which sometimes does) it will be a progress, doing 2048 is going backwards. And there are cases of cds like PCE, pc protections etc that require raw data and/or subs too. For consinstecy we treat all cds the same.