ok then, thank you very much, Rocknroms

but it's not always like this in db, for example Sega Saturn Grandia Limited Edition is Alt
so i asked

http://redump.org/disc/2027/
i have same same game, but Original release, v1.003
is it Editions, versions or Alt in dat?

in TOSEC it's alike to what Rocknroms suggests:

The TOSEC Naming Convention v1 wrote:

* (Disk/File/Tape x of y Side A/B)
This field is used if the game spans more than one disk, or is comprised of
multiple files. When there are 9 or less disks, the format of (Disk 1 of 3)
is used. If there are 10 or more disks, then the entry needs to change to
(Disk 01 of 13) to maintain consistency. In cases where double sided tapes
or disks are involved, the "Side A/B" entry is also included.
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(File 1 of 2)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(File 2 of 2)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Side A)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Side B)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 01 of 11)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 08 of 11)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 10 of 11)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 1 of 2 Side A)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 1 of 2 Side B)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 2 of 2 Side A)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 2 of 2 Side B)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Tape 1 of 2 Side A)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Tape 1 of 2 Side B)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Tape 2 of 2 Side A)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Tape 2 of 2 Side B)"

** NOTE: In cases where multi-file zips are used, the parent's zipname should
reflect the contents of the zip.
The files :
"Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 1 of 2).bin"
"Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 2 of 2).bin"
would be included in the zip called:
"Legend of TOSEC, The (1986)(DevStudio)(US)[2 Disks].zip"

* (disk label)
If the disk label is known, this field following the (Disk x of y) entry
should contain it. This is mainly used when save, program, install, or
other custom names might be requested by the game itself. (Disk 2 of 3) is
not useful by itself when the program asks you to "Insert Character Disk".
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 1 of 2)(Program)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 2 of 2)(Data)"
Ex: "Legend of TOSEC, The (1986)(DevStudio)(US)(Disk 2 of 2)(Disk B)"

but it makes more sense there, since 1st field always denotes medium from a set - it has a different meanig
here it's only a counter: A, B, C or 0, 1, 2 or I, II, III can be a counters too
so in TOSEC also Enemy Zero would be with labels

(Disc 1)(Disc A) and (Disc 1)(Disc 0) overlap, but (Disc 1) does not express this situation fully, imho,
(Disc 1 of 2)(Disc A) would, as would (Disc A) <- not as complete as previous one though, but that's what we got
also it's the same with (Disc 1 of 4)(Disc 0) and (Disc 0), though 1st is more descriptive again, both are fine, imho

ok, thank you provato, this is a good thought imho

game in question is Dracula Detective for Saturn

it indeed also internally refers to CDs by letters
http://img39.imageshack.us/img39/4323/ddssf.jpg

which curiously enough isn't the case with PSX version
http://img259.imageshack.us/img259/8370/ddpsx.jpg

should Disc number be filled with 'A' and 'B' instead of '1' and '2', if that's how it's printed on media?
it's 0..3 instead of 1..4 for Enemy Zero after all

ther's commandline program that would convert .cue, .bin (split in tracks, as on redump.org) & .sbi into .ccd, .img, .sub
http://www.mediafire.com/?5myjkuymijl
addittionally you'll need to supply XOR constant: either $8001 or $0080
those values can be found in DB
e.g. for Crash Bash it's $8001

please test on emulator before actual recording
(mount image, select ePSXe CDR plugin, select corresponding drive and enable subchannel reading -> Run CDROM)
e.g. Crash Bash would hang on Loading screen, just after intro / before stage select

107

(5 replies, posted in General discussion)

thank you Nologic
it looks very nice imho

108

(5 replies, posted in General discussion)

hello Nologic

yes, i think it would look better with those Data Type options grouped togeather,
basically listing just sizes or shortened list
and maybe additional Amount alternative expressed in sectors could be useful
also you would have to generate subcode when padding 2448 images
else you might end up with damaged image / CD
so maybe it's better to gray out this particular case

I never said you are dumb, I said your ideas, the ones on renaming, are dumb. Do you know the difference?

no i don't

neither did i say you are dumb or even your ideas are dumb if that matters to you - it doesn't to me

Rocknroms wrote:

(yes themabus, go on with your "black" about me even suggesting I had deleted my own posts. Here you have passed the border, I like you to know!).
Normally people move discussion to a personal stage when they have no more ideas about the real discussion.

Rocknroms (previously in this thread) wrote:

it's not me who wanted no-intro convention, but it seems that somebody is using no-intro convention to match his wishes (see also what Fireball said), am I wrong? (pointing @me)

It's quite clear that somebody is taking decisions about any aspect of the project justifying them with stupid or no sense matters or simply because they find this matters "cool". When somebody asks about, the only replies hide (or not) stupid or no sense matters or "because I like and it's cool". (obviously pointing @me)

Ok, you don't understand anything, sorry!
No-intro doesn't mess up anything, if you really want to hear from me: it's you and another pair of mods who messed up anything.
Is it me who make changes in DB to accomplish his desires of renaming?
please don't put in my mounth words I've never said just to justify your ideas
Also other changes you suggested can help only leechers or collectors of roms and not DB integrity. It's not so difficult to understand,

if you don't understand I think it's vain
I have nothing against no-intro but only how it seems you and some others want it to be used
First I'd like you and all to understand
indeed someone seemed to ansious to go to no-intro (presumably pointing at me)

Ah and again, you didn't understand anything even if I explained line by line
You haven't understood yet that in all my posts you report up again I was referring to your fantastic suggestions and how someone (see you, for example) wants to use no-intro switch, like a great fun game.

haven't you passed this border long before me, Rocknroms?

Rocknroms wrote:

About Fireball, he said explicit that Dremora is working on a new DB when he replied you, and his words are very similar to mine... so what the fuck I have to tell him? Who is ignoring whom?

F1ReB4LL wrote:

I just hope Dremora is serious about writing a new site, where noone will be able to edit the entries so easy, because with such a "smart" crew, which members rename everything 10 times a month on their own without any discussions and without any logic, this project is going into f@#king nowhere. Over.

talk to Dremora or write your own generator or make/fix the dats manually and host them somewhere, but don't even dare to tweak the DB fields to match your f@#$ing dats! I've already tired of massive renamings by themabus and Jackal, which clearly look to me like acts of sabotage in order to screw the database. Guess, we'll be forced to harshly reduce the number of mods soon.

where? as i see it basically F1ReB4LL told i should go play with myself

Rocknroms wrote:

Yes and for example this is the "old renaming we used" because tel ns. are serials. Another of your suggestions.
Ah and again, you didn't understand anything even if I explained line by line.

it's an general attribute from real life, opposite to artificial v1.x or Alt, it could be serial in some cases
but you don't understand this, Rocknroms: serials generally won't work -
they can not replace editions, they do not apply to all systems the same,
not even all regions and would you have serials it should be then whole set not just 1st one
otherwise you're loosing data from output - it doesn't map back to real media anymore - it's useless
it's like you'd have a db of cars for example
and there would be that particular Ford model from year 1980, 1981 and 1982,
different colors, tires - such little things
and you'd make an catalog listing only Ford (1980), because it's oldest or something
one of those later releases could come with some accessories probably
but in your catalog you would still associate those with this (1980) as if they'd come with every single release
what sense does this make?! it's a crooked reality - not the way things are
why would anyone want to use this catalog?

Rocknroms wrote:

You haven't understood yet that in all my posts you report up again I was referring to your fantastic suggestions and how someone (see you, for example) wants to use no-intro switch, like a great fun game.

could you elaborate, please

what i'm suggesting all the time is to modify db to actually have those additional flags
(no-intro, largely because you kept protesting everything else, because you like serials so much)
with some specific to redump.org corrections applied (like editions for example)

i thought we pretty much agreed on everything earlier today,
even editions, that you protested so passionately all the time,
except cases where there would be multiple ones

now you go again about how great it was with serials and how i'm messing it all up
those problems i noted - originating from lack of flags and rules we had and still have,
and those listed are by no means all,
do not exist in your universe, i guess
would you keep sticking single internal serial to multiple editions,
creating flags within title and version fields, breaking records apart with v1.x or Alt, etc?
well it's not even an database it is a mess, Rocknroms, databases do not work this way
it is a pity you do not see this

Thanks for reporting something I wrote that was deleted so it's more clear that I have nothing against no-intro but only how it seems you and some others want it to be used.

you're welcome

First,  to match DB and dats you have to change DB structure and you cannot add tags in game name to match no-intro. You'll have perfect no-intro dats but a confused DB, I think Fireball wants to say the same.

that's what i'm trying to say, i don't believe F1ReB4LL thinks the same though

F1ReB4LL wrote:

we've switched the naming to No-Intro's convention

F1ReB4LL wrote:

Demo, Taikenban, Sampleban, Sample, Promo, Hibaihin, Not For Sale, Shikyouhin, Mihonhin/Mihon Hin, etc. should be in Edition. You can name it Sample, Demo or whatever in the dats, it's not that critical.

F1ReB4LL wrote:

People, we're not a set of dats, like No-Intro, we're a DATABASE, which has its own fields, which should be properly filled for each entry and dat generation here is a secondary feature. If you don't like the naming in the dats - talk to Dremora or write your own generator or make/fix the dats manually and host them somewhere, but don't even dare to tweak the DB fields to match your f@#$ing dats!

Rocknroms wrote:

This is another of yours, so indeed is it good to have 'John Smith (rev A)' & 'John Smith (rev B)'!?

no, but you could have e.g. John Smith (555-1212) & John Smith (555-7777) denoting telephone nr. for example

I concer with you that we have to use EDITION flag to identify a dump, but this way for example:

Game 1 (USA)

Game 2 (USA) (Limited)

and not

Game 1 (USA) (Original)

Game 2 (USA) (Limited)

sure, the same as with most flags for no-intro - ones with default value are omitted

and if you have this situation:

Game 1 ---> One Limited and one Original dump match
Game 1 ---> One or more Limited dumps

like this again

Game 1 (USA)

Game 2 (USA) (Limited)

and not

Game 1 (USA) (Original, Limited)

Game 2 (USA) (Limited)

no, the other way around - the same as with the languages
(e.g. you don't drop them whenever English is present)
by transferring partial information to output you loose relations
there could be bonus media bundled with Limited Edition for example
or it could happen that CD1 of other edition match with Original but CD2 don't
but generally this is information that just shouldn't be lost -
if it's 'Custom Edition' in real life - that's how it should be in db, that's how people will look it up, 
and that's how it should appear in .dat respectively

I's obvious we have to make changes to no-intro convention, but we aren't no-intro even if some no-intro members are also members here.
We had to change DB and to find a no-intro compromise before switching to no-intro, indeed someone seemed to ansious to go to no-intro.

sure, why did you seemed so amused to extent of clapping when i said that?
http://forum.redump.org/topic/4771/nointro-naming/

Rocknroms wrote:

Clap clap!

This is the chaos that will be and why I don't agree with the change. Who cares if Bonus CD is in a Limited Edition or not? It's archived in DB, what else do you need? So why not adding even dates (please in this case insert also "A.D.", it's more cool!), company and so on like tosec shit?
Themabus, this oddity again?
And so we have to write a poem? Why not adding even the birth date of Publisher's dog as I said?

and you go on after little while

Rocknroms wrote:

Again I see other comment about avoiding v.1x, etc. THIS IS CHAOS! And I respect everyone's opinion, but there's a limit to this.

I thought you understood but I was wrong.
When you have "Limited Edition" in DB what the **** do you need to add it to dat name?
Moreover, a lot of CD media were moved from their real case (rental, etc. I did it too for some cds of my collection because they were damaged. Most PS2 discs are the same on Original and other editions, and so on) so how could people really know at 100% if they have a proper edition? And you want to add this bullshit even in dat names?

maybe i'm seeing black again

This has nothing to do with old renaming or no-intro. These are simply mistakes and no-intro doesn't solve anything.

but it does, there simply were not enough flags to handle this and even less rules resulting in situation we have
where would you put (Demo), providing  Version and Edition field are both already filled?

Indeed for Bonus CD it's different IMO, this has to be shown in DB filenames as they are no edition or else. Or did you want to add "Bonus CD" in Edition for more confusion!?

no, i would prefer to mark Bonus with stand alone flag alike to Demo, Beta, and so on
(maybe it even could be this same 'Devstatus' flag, i'm not sure,
i would have to check ordering and situations there currently are in db)
title is just that - title

Yes so it's implicit that DB is father of .dat, you have to change DB structure to output correct dats (something that Dremora is doing) but you cannot adapt DB field entries to match no-intro or other wishes.

then why didn't you let this opinion be known to mr. announcer or whoever is pushing him around?

You want to use .ISO, ok but I have no rational reply. Simply.

to be frank i couldn't care less about this extension
wouldn't you attack no-intro and pakkiso (that's how i saw it, i'm sorry) i wouldn't reply at all
i tried to explain to you how i see it, though, why this change could have been made - you keep ignoring it
you kept ignoring what iR0b0t and other people wrote - those posts are deleted now
maybe you did it yourself - i don't know, it wouldn't surprise me
if you didn't, ask Dremora to look it up in logs

Rocknroms wrote:

I never said anything bad about no-intro and I'm not against no-intro (only I don't like the "full country" flag)

title reads 'Gamecube renaming after moving to no-intro...'
here's what you said about no-intro in this thread alone:

Rocknroms wrote:

PS: If you want no-intro use at least custom estensions for equal sized images (gamecube, wii) as they do.

Ok another point to chaos. By the way it's not so important, it's not me who wanted no-intro convention, but it seems that somebody is using no-intro convention to match his wishes (see also what Fireball said), am I wrong?

Because you have choosen no-intro and naming convention have a different extention for Nintendo stuff? Because they are non common DVDs?

Huh, it has a lot to do. Why did you want no-intro (including all other changes)? Read again all the posts about (the old ones).

We (not everybody and a minority) choose to change to no-intro.

Uh 2, yesterday we have to put stupid flags in dats because people cannot understand if they have a good dump, now we have to use hacked dumps extensions because people knows we are redump. What do you decide tomorrow?

quite obvious to me you create association of this topic, which you are upset about, with move to no-intro convention
'another point to chaos', 'stupid flags', 'hacked dumps extensions'
you do drag your negative feelings about no-intro along
'it's not me who wanted no-intro', 'you have choosen no-intro', 'Why did you want no-intro', 'We (not everybody and a minority) choose to change to no-intro'
you disassociate yourself from decision to move to no-intro,
hence putting youreslf in opposition as if no-intro=bad, you=good

i'm sorry if i misunderstood anything

Rocknroms wrote:

Where did you read I wrote about leechers = no-intro or similar, please don't put in my mounth words I've never said just to justify your ideas. I spoke of leechers = pakkiso and nothing else, is that wrong?

Rocknroms wrote:

Ok, now I understand... another change made only to help leechers (see pakkiso compression), am I wrong?

here you go about leechers reffering to change of extension, i'm not making this up

Also other changes you suggested can help only leechers or collectors of roms and not DB integrity. It's not so difficult to understand, I said read all old posts about.

could you explain please, what changes can help leechers?
how one (besides wrong one) from several (broken relation) serials in filenames
and separation of records with generic flags contribute to db integrity?
as far as i know you fill db with data from real life, you do not make things up when it gets complicated
for example: if you'd have records of people and there would be 2 persons 'John Smith'
you'd use person's id or father's name, or birthdate, or telephone nr., or address -
something real to make it clear which person is referred to
under no circumstances would you do this: 'John Smith (v1.0)' & 'John Smith (v1.1)', even if they're twins
.dat is just an output of db, it should not present different data from what is in db
it could exclude some flags or be shortened with abbreviations for example, but not create completely different relations
what makes you think it's different with CDs?

Rocknroms wrote:

but I've simply always said it's not suitable for CD media and I think everybody here saw the problems we have now, DB against dats.

most problems i see are legacy from previous naming:
flags being filled with conflicting values, e.g. (demo) in 'Version', when there is version present,
or in 'Edition' when there is one
conflicting real versions with artificial ones, leaving 'Alt' as only means of breaking such records apart
pseudo-flags in title field denoting bonus medium or edition, etc.
broken relations with bonus media
neglecting those problems any longer would only make situation more severe in future
no-intro actually provide means to resolve those problems by introducing additional flags
and definitions of how to use them, though some changes are required, imho, i'm not denying that

Rocknroms wrote:

What's the meaning of this reply? what have to do all this with GC? If you don't know to much about GC why do you reply?

i reply like this because you keep drawing parallels between GC and DC
(if it's different with GC don't do this please)
and blaming no-intro for messing this up to be leecher friendly, portraing no-intro as something rather negative
(as opposite to you presumably motivated by more noble intentions)
which is absurd anyway - no-intro naming convention do not define extensions
if they were changed at same time it must have been a coincidence
and i'm yet to understand what leechers have to do with this

Rocknroms wrote:

The only other system with needs a specific drive to dump its discs is Dreamcast because it's not a standard CD (you can say that all systems in DB are not standard CD, but this is not true. Protection, subcodes or TOC don't change anything! The only non-standard one is DC). And I never said to rename DC extension.

it doesn't matter how many drives can read what
hardware gets more flexible with time and standards get expandet - it's an variable you're basing your classification upon

Dreamcast's GDs are the same Saturn protection + HD area + modded TOC

what about 90 minute CDs, 99 minute ones? Plextor's GigaRec? Overburning?
TOC you can modify yourself with .ccd for example
twin sectors, deliberate bad sectors - not every drive will read those right
CDs with larger offsets? - you need drive capable of overreading to access this data
and not so long ago you basically wouldn't be able to read RAW data as well as full subcode at all
you do need custom media to duplicate PSX or Saturn CDs as well as GDs, or maybe modded hardware, or both

the point is - it's not pits & lands or spiral revolutions stored in DB, it's information about logical layer
which is alike for all of those systems

you could include file which would define ring for every Saturn CD, wobble for every PSX, ring & HD for DC, etc
(or note those differences with flag or extension for that matter)
but it simply is useless because it applies to every medium from set in the same way

another change made only to help leechers (see pakkiso compression)

i'm sorry, this must be something good then, ok

On your logical level, as you said, even DVDs are CDs.

no, it's completely different medium - it's not CD, just larger.
i mean: all differences you want to note about DC GDs or PSX CDs or Saturn CDs or PCE CDs, etc.,
since all of those do have some non standart characteristics
(i hope you don't want to have different extension every time something doesn't match with ISO specifications),
you can do with metadata, if required at all
(well it's not particularly useful for PSX or Saturn, imho, since you can not reproduce those differences anyway
and could you reproduce them it would be the same thing for whole set, so why bother marking every medium?)
but ther's no need to make it so apparent, imho

Because you have choosen no-intro and naming convention have a different extention for Nintendo stuff? Because they are non common DVDs?

previous reply, moreover *iso Gamecube images you can find around are normally hacked, fixed, etc. and *.gcm is the regular extension used for Gamecube games.

listen, i won't predend i know anything about GC, but if it's the same as with those CDs -
basically moded DVD that do resolve to DVD on logical level after processing, i don't think it matters
if it's something different, like different medium - by all means, name it anything you want

Rocknroms wrote:

Ok, now I understand... another change made only to help leechers (see pakkiso compression), am I wrong?

ok, so what's wrong with pakkiso? help me to understand please
besides whatever might be wrong with it - you don't have to use it

Rocknroms wrote:

Oh well, if different data frame has nothing to say, probably it's real we can dump GC/Wii with plextors! You have said this.
Nobody said 2048 is RAW, neither me. Images are extracted RAW and decrypted/unscrambled/converted on the fly to 2048 but you cannot call these normal ISOs because of all the points I wrote above. It's like affirming "GDroms are CDs" and in DB at least Wii discs are called "Wii Optical Discs" and not "Wii DVDs", same has to be changed IMO for GC.

i don't know anything about GC, but since you mention DC -
on logical level they're just ordinary tracks the same as on CD
they're not handled differently (except shortened naming which is wrong imho & metadata), why should they be?
if it's similar with GC how will extension help?
what has leechers to do with all of this?

yes

however with larger negative offsets (-48..), if you don't want to open your drive up and it doesn't support d8 command,
you would not be able to determine correct offset, but you could still verify ones already in db

118

(11 replies, posted in General discussion)

How do I do this?

could you extract track that precedes data track (Track 01 usually) with IsoBuster and take a look at it with hex editor, please?
what does 1st and last data sectors (i mean those at the end, from 2nd part of gap) look like in there?

Should the pregap for track 1 be showing as 2 seconds in EAC?

yes, usually
only a couple of Audio CDs had it different so far, i think

What is the swapping method?

basically you prepare drive so cover can be removed freely, then place Audio CD in tray, let drive detect it,
wait until it stops spinning, without ejecting tray remove cover and replace Audio CD with one you are going to extract
and put cover back on, so drive still thinks its an CDDA and will process your CD this way -
as one continuous stream of audio data (so no gaps at all and it will allow to read as far as TOC of Audio CD goes)
it's described in more detail here
except you don't need special Trap CD - any fairly large Audio CD should work
and extraction can be done with IsoBuster

So it's funny for you?

yes, you're a funny guy, F1ReB4LL

orly? Your mass renamings to "double names", confusing other people, which prefer to add similar double names into db now? So it's my fault and I can't read?

excuse me, what?
r-e-a-d:

would there be no-intro implemented with addition of separate 'edition' field
this is one of those things i wanted to talk about, once Dremora is back

I was asked to announce it, that's all. That doesn't mean I support ruining the database, which is being done by some members.

well then maybe you should stick to anouncing stuff
when you're asked

lol, F1ReB4LL, you top yourself with this one,
can you read like at all, or perhaps you simply lack basic understanding of things?

well yes, guees what, you have to actually do something, make those fields, update code - do something
bragging on 1st page about no-intro being implementet won't make it happen

yes i completely agree with you, BitLooter, but, as i understand it, most of the staff don't want it that way
because it's too long, or too TOSEC, or something
in no-intro flags are shown to break appart records, at least that's how i understand it, so it could be compromise

it could be:
SimCity 2000 (Special Edition) (Jewel Case)
with 'Jewel Case' in Additional
with both those flags being managed automatically for .dat output,
i.e. becoming visible or invisible depending on presence and state of other records
(e.g. in case ther's other 'SimCity 2000', (Special Edition) would become visible,
in case ther's other (Special Edition), also (Jewel Case) would be shown)
would there be no-intro implemented with addition of separate 'edition' field
also this record would resolve the same way
and those would too:
http://redump.org/disc/4501/
http://redump.org/disc/4496/
http://redump.org/disc/4504/
http://redump.org/disc/4498/
http://redump.org/disc/4499/
this is one of those things i wanted to talk about, once Dremora is back

123

(11 replies, posted in General discussion)

when EAC can't overread it often removes more data, than drive actually can't fetch
(i.e. more than those 40 bytes in this case)
on some drives this amount depends on whether Overread option is checked
it is an known issue with this program
so in this case, since audio is pretty close to track's end, actual data end up being removed by EAC

so, yeah, it should be this way - EAC's file is messed up
IsoBuster's is correct, once header is replaced with $00

about other drive - i guess it has exactly same or close offset
and EAC can't overread as well, not all drives report errors though

you could try to disable Overread and see what happens
but please don't leave this option that way, because generally you won't know when data was lost then
or leave it on for one drive and off for other, if you're going to use both
still on PCE offsets are pretty large sometimes, like 5 sectors or so - you won't be able to overpass those this way
so it's really better to be able to overread

124

(11 replies, posted in General discussion)

unfortunately it look like your drive can not overread at all
and IsoBuster inserts generic Mode1 sector there
you need only 40 bytes from that last sector though and since they're preceded with a lot of silence (0x00)
they're very likely to be just silence as well

Everything after 30364320 bytes should be trimmed, correct?

yes, so you'll end up with header from 2nd pic at the very end,
please replace it with 0x00 since IsoBuster made this data up
and i guess what you'll get will match to EAC file then
so trouble for nothing basically
but anyway you know now that your drive does not overread into Lead-Out
so you'll generally have problems with positive combined offsets at least,
still if there is no other drive available it's possible to overcome this with swapping

125

(11 replies, posted in General discussion)

this is usual EAC behavior for situations it can not get all data from CD
so it's either because this drive can not overread at all or EAC can not overread with this drive
you could try to take a look at the end of last track with IsoBuster's Sector View:
go to the last sector and then to the next one - if drive can read it then it's EAC problem
and so you should be able to extract this track as sector range: Extract From-To command
start and end LBA values will be preset in this dialog (42934; 55843)
increase either Length or End LBA by 1, hit Start Extraction and afterwards Cancel twice

since your offset with this drive appears to be 10 from those logs you posted
remove 10 samples (40 bytes) from the beginning of file you'll get (CD Segment.bin)
and (2352-40=2312) from the end
(btw this fragment you remove from the end should contain no data: all be 0x00,
otherwise offset value likely is wrong)
so final size should be 55843+1-42934=12910 sectors = 30364320 bytes
and so this is last track with corrected offset - it should match to one extracted with EAC
except former will have more meaningful bytes at the end, where it's all 0x00 already in EAC version