Current State of the Project

[dataO1]

I stumbled upon this repo, while researching about rekordbox internals. My idea was to write a rekordbox TUI in Rust and your library is an essential part of building such an application, so my questions are:

• Do you work around the documentation about the pdb and anlz files, reverse engineered by the deepsymmetry guys (this)? Skimming over the code, it looks like it.
• What is the current state of the project? What is already implemented, what is missing and do you have some sort of roadmap?
• How can i contribute? I am fairly new to rust.

Edit: Something, that would be important to me is, exposing the internal structs and types in order to build up a database from fresh without parsing an existing database. Do you plan to support something like that?

[Holzhaus]

• Do you work around the documentation about the pdb and anlz files, reverse engineered by the deepsymmetry guys (this)? Skimming over the code, it looks like it.

Yes.

What is the current state of the project? What is already implemented, what is missing and do you have some sort of roadmap?

I started just a few days ago :) The pdb parser is almost done (except for some instances where I used unwrap() instead of proper error handling). The anlz parser only parses the basic structure, not the individual sections until now. Some section parsers have been implemented in PR #3.

How can i contribute? I am fairly new to rust.

Sure, always happy for help :D

Something, that would be important to me is, exposing the internal structs and types in order to build up a database from fresh without parsing an existing database. Do you plan to support something like that?

Sure, in the end this library is supposed to support both parsing and serialization (similar to what triseratops does for Serato data). However, it's unclear if that will work until the format has been fully reverse engineered.

[dataO1]

That sounds really promising!

I've looked a bit deeper into the documentation of the pdb format...it's huge mess as far as i can see, this whole tables/pages/rows thing reminds me of operating system memory management.
It's insane to me that you coded the pdb parser down in 4 days! Also nicely documented and all, looks really good!

Right now I am trying to get a better understanding of all the parts, I hope it's fine if i ask some questions here, I just started researching about this whole topic today.

So, it seems that we are a little bit in a stale situation regarding reverse engineering the format, is that right (There hasn't been any updates on the crate-digger repo since a few months)? There are obviously some missing fields here and there, especially in the Page struct, it's hard for me to evaluate if these are important missing pieces or if the current status is sufficient (or close to) for building working databases with tracks and maybe even playlists etc. that players can read.

[Holzhaus]

I've looked a bit deeper into the documentation of the pdb format...it's huge mess as far as i can see, this whole tables/pages/rows thing reminds me of operating system memory management. It's insane to me that you coded the pdb parser down in 4 days! Also nicely documented and all, looks really good!

Thanks!

So, it seems that we are a little bit in a stale situation regarding reverse engineering the format, is that right (There hasn't been any updates on the crate-digger repo since a few months)? There are obviously some missing fields here and there, especially in the Page struct, it's hard for me to evaluate if these are important missing pieces or if the current status is sufficient (or close to) for building working databases with tracks and maybe even playlists etc. that players can read.

This is hard to say, we can only try to write a file and "guess" the unknown field values, then check if a player actually read it.