Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Note - Files that refer to sectors outside of the current track/volume #9

Open
ehw opened this issue Jul 26, 2024 · 2 comments
Open

Comments

@ehw
Copy link
Collaborator

ehw commented Jul 26, 2024

Currently, ps2exe doesn't calculate sums with data files within a volume in instances where that file's data lies in a sector outside of the current data track. This was done purposefully as originally, we didn't want to make disc images unique on the output csv if they only differed by track offset or some other mastering data that isn't interesting to note for comparison (like audio mastering differences). We were only concerned with just the files with sector data within the current volume themselves.

However, files can have data stored in separate data tracks outside of a given volume. These data tracks can even have sync information and EDC. This is different as the contents of the files could have been stored within the volume unaffected by offset but for some reason were stored in different tracks outside the existing volume's sector range. The sync information will be present if it's a properly dumped data track and that will be an indicator that the sector being referred to by the file is data and not audio/video streaming data that can shift from different masterings.

@ehw
Copy link
Collaborator Author

ehw commented Aug 17, 2024

This kinda only applies to split tracks vs all inclusive formats like .img, where ps2exe does look at data if its referenced to a certain extent outside the track. For split tracks like redump style dumps, it fills the data with 00.

@Sazpaimon
Copy link
Collaborator

Slight correction: Files that are not found outside of the track are not considered for hashing if 0 bytes could be found for them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants