cant you just mount the whole thing?
All my posts and submission data are released into Public Domain / CC0.
2 2009-06-23 03:25:04 (edited by DJoneK 2009-06-23 03:37:08)
I can point at least 1 benefit in having tracks separated. Patches. 
EDIT: Plus, no need to redump/rerip if you want to create "special" compilations.
Plus it allows you to import tracks from other games without having to split them up first.. and it also provides more insight in whether the tracks are dumped correctly (they can be compared to other regions etc).
ripping CD audio is a pain in the ass, but when you do it as a CD image its much more likely to be correct and it should be much easier to mount, no?
All my posts and submission data are released into Public Domain / CC0.
user7 wrote:
ripping CD audio is a pain in the ass, but when you do it as a CD image its much more likely to be correct and it should be much easier to mount, no?
Likely to be correct -> no, why should it be more correct?
Easier to mount -> .cue file does everything, you don't have to mount every single track one by one
- iR0b0t
- Administrator
- Offline
is mounting of multiple images possible? *rolleyes* dont see any sense in it 
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
gigadeath wrote:
Likely to be correct -> no, why should it be more correct?
a single file is obviously much more manageable and you dont need to deal with the issue of gap accuracy which may result in mismatching file checksums for the same disc
All my posts and submission data are released into Public Domain / CC0.
- iR0b0t
- Administrator
- Offline
user7 wrote:
a single file is obviously much more manageable
not really, and if you wanna dump the disc as a single image you would need to dump it scrambled
user7 wrote:
you dont need to deal with the issue of gap accuracy which may result in mismatching file checksums for the same disc
there are no issue, and file checksums for the same disc arent different !!!
PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)
9 2009-06-23 21:24:44 (edited by user7 2009-06-23 21:25:04)
iR0b0t wrote:
there are no issue, and file checksums for the same disc arent different !!!
okay, but i remember themabus and fireball arguing a month or so ago about gaps being rounded and subchannel data reporting different gap sizes on different drives with different software differently :S
All my posts and submission data are released into Public Domain / CC0.
You could dump all the audio to a single file and specify tracks in the .cue file, but you'd still have the same gap issues. It would be easier to correct gap errors in a cue file instead of moving data around, but the convienience of multiple tracks outweigs this in my opinion. A correct gap structure is part of a good dump so there's no way to get around it.
oic, i'm ripping a cd for the first time in EAC in a week or so. i just put it in three times and got different values for gaps each time lol
All my posts and submission data are released into Public Domain / CC0.
That can happen if the cd is scratched. Beyond that make sure your gap detection is set to 'secure' and try the all the gap detection methods (A,B,C) and see if one of the other ones gives better results. If that doesn't help it may be a drive issue.
yes indeed it was scratched. greynol from hydrogen audio explained that regardless of what gap time is detected, the final output will be the same. in other words whatever the subchannel data says in relation to gap times, the final output (and checksum) will be the same. at this point i wonder if subchannel data has any relevance at all.
All my posts and submission data are released into Public Domain / CC0.
the gaps determine the individual track sizes..
at this point i wonder if this thread has any relevance at all.
15 2009-06-24 22:50:46 (edited by user7 2009-06-24 22:52:13)
maybe this thread doesnt and i'm just failing to understand something, however this is the issue as i see it.
1. different gap sizes can occur for the same cd/cd-rom
2. ripping tracks individually will result in size deviation between multiple rips if gaps deviate (according to Jackals post above), however according to greynol, if gaps deviate, this has NO effect on the end result/checksum (see: http://www.hydrogenaudio.org/forums/ind … opic=72969 )
3. ripping the cd-rom as a single image will not influence size (even if gap sizes deviate), thus are more likely to be correct dumps
maybe i'm just overthinking this or inserting a problem where it is not necessary. i didnt start this thread as a criticism by any means and maybe this issue is only relevant with scratched CDs, however after reading fireball and themabus's 2/3 page argument on subchannel accuracy, i became curious on the effect of mismatching gap size on the accuracy of dumps.
dude, cd-roms are an asspain!
All my posts and submission data are released into Public Domain / CC0.
1. different gap sizes can occur for the same cd/cd-rom
Generally no, fireball and themabus's discussion regards the question of wether an improperly mastered disc with subcode that indicates the wrong gaps should be 'corrected' by rounding to get back the expected pre-mastering tracks. If one of these incorrectly mastered discs is read multiple times it would show the same gaps (just arguably incorrect ones).
This only applies to older systems that had this issue. (i.e. Sega CD).
2. ripping tracks individually will result in size deviation between multiple rips if gaps deviate (according to Jackals post above), however according to greynol, if gaps deviate, this has NO effect on the end result/checksum (see: http://www.hydrogenaudio.org/forums/ind … opic=72969 )
According to greynol in regards to weather CRC with be different:
Depends on what you're telling EAC to do with gaps.
Gaps won't effect track crcs if "No use null samples for CRC calculations" is checked in EAC, so long as the gap isn't so far off as to push data past the track boundary. We want track timing to be correct as well as the track data, so we include the leading and trailing zeros in our Hash calculations.
3. ripping the cd-rom as a single image will not influence size (even if gap sizes deviate), thus are more likely to be correct dumps
True, but the track timing will deviate resulting in an incorrect gap structure in the cue. In essence the important data on a cd consists of the data and audio tracks and the subcode that indicates track gaps.
Since the subcode can't reliably be dumped with matching crcs we use EAC or other methods to get the track layout and store that information in the cue file. In other words the .cue file captures all the important information from the subcode. Dumping with no gap detection would result in repeatable data and audio track dumps, but we would permanantly lose the subcode information.
17 2009-06-25 00:56:59 (edited by user7 2009-06-27 06:00:48)
alright, i think i understand after than explanation. thanks.
edit: i found out that EAC has an option to "securely" detect gaps. it keeps testing them until they get 3 matches
All my posts and submission data are released into Public Domain / CC0.