Add support for more Id3v2.x fields

[notryanb]

There are many fields not currently being output to the user.

• comments
• lyrics
• date records etc...

Review the rest of the rust id3 crates docs and output the rest of the available data.

[Delapouite]

Hi

As you stated, the plugin currently maintain a hard-coded list of fields to display. While testing it on a few tracks in my collection, I was surprised to see nothing in the column "year" whereas this information was definitely displayed in my music player.

It turns out that the .year() function rightfully shows the content of the TYER tag. But my files are using the TDRC tag.

Long story short, how should the plugin behave regarding exhaustivity?

• do we want it to always display the same fixed set of columns, which can often lead to blank content?
• do we want it to display a list of column passed as arguments?
• do we want it to iterate through .frames() and display everything? with a --full argument?

Thanks

[notryanb]

Wow, thank you for taking interest in the project @Delapouite! This is my first project doing any sort of work on media file metadata and I have a lot to learn about the standards.

re your questions:

• do we want it to always display the same fixed set of columns, which can often lead to blank content? I have not yet thought this through, but I think some way of grabbing the frames might be the best option. I share the same concern, where the id3 crate might not expose certain frames as convenience methods through the api or there are more cases like you've just stated where the same data can be expressed across many frames.

• do we want it to display a list of column passed as arguments? / do we want it to iterate through .frames() and display everything? with a --full argument? nushell already solves the problem of picking which columns should be displayed through get and pick. ex id3 | pick artist album. I like the idea of a --full flag being in there where everything can be extracted leaving the user to pick which columns. My concern is the mapping of column names to frames. In the --full case, should the column names be the frame names or the human readable names? I suppose that could be a flag as well.

I could potentially see a use case where someone wants to grab all the frames and put them into a CSV, JSON, another format and then use nushell to send it to an API or something like that.