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.

Sign up for GitHub

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

Jump to bottom

Database Exports Documentation: Color ID really sometimes 8 bit and sometimes 16 bit large? #27

Open
Holzhaus opened this issue Apr 7, 2022 · 1 comment
Open

Database Exports Documentation: Color ID really sometimes 8 bit and sometimes 16 bit large? #27

Holzhaus opened this issue Apr 7, 2022 · 1 comment

Comments

@Holzhaus
Copy link
Contributor

Holzhaus commented Apr 7, 2022

In track rows in PDB files, the color ID field is just a single byte (cid at offset 0x58). The same goes for the color index in Extended (nxs2) Cue List entries of analysis files (cid at offset 0x1c).

But for PDB color rows, the documentation states that the field is 2 bytes large (id at offset 0x05). Is there a reason to believe that this field is not just also a single byte, and the second byte belongs to u3 or is yet another unknown byte field?
Holzhaus added a commit to Holzhaus/rekordcrate that referenced this issue Apr 7, 2022
@Holzhaus
fix(pdb): Use 8-bit color indices consistently
f052a09 
Before, we sometimes used 8-bit indices and sometimes 16-bit ones,
because the reverse-engineered format documentation described it that
way.

However, these does not seem to be a good reason why there should be
16-bit color indices when the value it contains is just 8-bit. It's
likely that the most significant byte actually belongs to another field.

Also see:

  Deep-Symmetry/crate-digger#27
@Holzhaus Holzhaus mentioned this issue Apr 7, 2022
Merged
Holzhaus added a commit to Holzhaus/rekordcrate that referenced this issue Apr 8, 2022
@Holzhaus
fix(pdb): Use 8-bit color indices consistently
1ee96eb 
Before, we sometimes used 8-bit indices and sometimes 16-bit ones,
because the reverse-engineered format documentation described it that
way.

However, these does not seem to be a good reason why there should be
16-bit color indices when the value it contains is just 8-bit. It's
likely that the most significant byte actually belongs to another field.

Also see:

  Deep-Symmetry/crate-digger#27
@brunchboy
Copy link
Member

Yes, looking at the context a bit, I agree that the color index is probably just a single byte, and that u₃ should just expand to take over the second byte of what is now the color id. Would you be willing to submit a PR to make those changes?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Holzhaus @brunchboy