Support for work/movement

[Haim Ashkenazi]

Hi,

First let me thank you for this crate. I was looking for a long time for a crate to write m4a metadata in rust (I had to write my current utility for managing work/movement in classical music in python because of that 🙁). I was really happy a couple of days ago when during my occasional searches I found this crate.

I'm trying to create a PR for supporting work / movement. This includes 5 new tags:

• ‘\xa9wrk’ - work name (string)
• ‘\xa9mvn’ - movement name (string)
• ‘\xa9mvc’ - movement count (number)
• ‘\xa9mvi’ - movement index (number)
• shwm - show work movement flag (as integer, 1 is true)

I have zero knowledge about reading/writing binary data. I managed to make it read a couple of these tags. For example the data is printed like this in the test:

        Atom{ ©mvc, 0, Content::Atoms{ [
            Atom{ data, 0, Content::TypedData{ Reserved{ [0, 4] } } },
        ] } },
        Atom{ ©mvi, 0, Content::Atoms{ [
            Atom{ data, 0, Content::TypedData{ Reserved{ [0, 1] } } },
        ] } },
        Atom{ ©nam, 0, Content::Atoms{ [
            Atom{ data, 0, Content::TypedData{ UTF8{ "Sonata in D minor for cello and piano, op. 40: I. Allegro non troppo - Largo" } } },
        ] } },

I have no idea why movement index/count is parsed as 2 items but the value is true.

I would appreciate any pointers on how to write the set_* functions for the following data types:

• movement count or index
• show work movement (probably something like cpil)

my main resource for the above tags is the mutagen documentation.

Thank you very much in advance

[Haim Ashkenazi]

Looking at swift example I see that the reason that movement index and count have length 2 is because they are u16.

[Haim Ashkenazi]

Ok, My first full implementation trial handles u16 and u8 incorrectly. See the output from AtomicParsley:

Atom "©mvn" contains: some movement
Atom "©mvi" contains: hex 0x0003
Atom "©mvc" contains: hex 0x000C
Atom "©wrk" contains: some work
Atom "shwm" contains: hex 0x01

I'll continue researching, appreciate any input.

[Haim Ashkenazi]

(feels like I'm talking to myself 🙂),

I think I solved the issues. I'll tidy up the changes and send a PR tomorrow. Hopefully you'll have time to review it.

[Tobias Schmitz]

First of all sorry, I didn't get any notifications from the github app and didn't see the mails. Thank you for the contribution, this looks good so far and I will merge it.
The only thing that is bugging me a bit is the additional type identifier when reading BE_SIGNED integers. I should have probably created a BeSigned enum variant before, but mapping it to Reserved was a lazy workaround. I will try to clean that up next week but for now this looks good to go.

[Haim Ashkenazi]

Thanks,

Do you mean creating a new type in Data? I don't mind doing it myself. It still would contain a Ver<u8> because there are at least two types that needs the identifier (i32 and i8). Let me know if you want me to do it.

[Tobias Schmitz]

Yeah that's what I had in mind. If you want to do it feel free.

[Haim Ashkenazi]

I'll get to it over the weekend. Thanks.

[Tobias Schmitz]

Thank you for your work.