search

Zeugma440 / atldotnet

Fully managed, portable and easy-to-use C# library to read and edit audio data and metadata (tags) from various audio formats, playlists and CUE sheets
MIT License
459 stars 61 forks source link

Request: Id3 tag field trimming, Genre bug? #200

Closed mikeatdjp closed 1 year ago

mikeatdjp commented 1 year ago

The problem

Just a little quality of life request- I have some files with BOM in the id3 fields that ATL doesn't trim, as well as other files with whitespace. Can ATL trim these?

Also I noticed sometimes I have Genre doubled, like Blues;Blues, Other;Other, or Rock;Rock. Can ATL just use the first one it finds? Actually i don't see it in the tags more than once, so I'm not sure where this comes from.

I can send you sample files for each issue.

Environment

Zeugma440 commented 1 year ago

Hey Mike,

Thanks for your precious feedback!

I have some files with BOM in the id3 fields that ATL doesn't trim, as well as other files with whitespace. Can ATL trim these?

You're actually pointing a guiding principle I've been following : don't alter any data while reading or writing it. In other words, what you set is what's written / what's in the file is what you get - even if there are BOMs and whitespaces ;)

Another argument is I haven't seen other similar libraries doing that. Their added value is the standard API they provide to hide the complexity of formatting and writing the right bytes at the right place. Unless ID3/vorbis/M4A specifications explicitely say whitespaces have to be trimmed, guessing which data should be cleaned up or which data is "valid" is the user's problem, not the library's.

Also I noticed sometimes I have Genre doubled, like Blues;Blues, Other;Other, or Rock;Rock. Can ATL just use the first one it finds? Actually i don't see it in the tags more than once, so I'm not sure where this comes from.

If you're unsure where it comes from, I'd love to see a sample for that one :)

Zeugma440 commented 1 year ago

@mikeatdjp Are you still interested in solving the 2nd part of that issue ? Or is it obsolete to you ?

mikeatdjp commented 1 year ago

Hi @Zeugma440 , Thanks for your reply. I am interested, I've just been on another project.

Another argument is I haven't seen other similar libraries doing that. Their added...

I actually found this comparing a large collection of tags processed by ATL to the same collection processed by TagLib. I just double checked and made sure we were not doing any extra trimming with TagLib but I had to add in the trimming when using ATL to match TagLib results. Also I remember inspecting some of these different tags in mp3tag and I didn't see the extra spaces in mp3tag. And of course BOM isn't visible anyway.

I saved some sample files, but I couldn't tell what your email was last time. Where should I post these? I just attached it here. We can remove it if that's not right.

Zeugma440 commented 1 year ago

Thanks a lot, you can remove the file now (and note my e-mail address /github name/ (at) [not-cold]mail {dot com} )

As for the genre bug, it comes from the fact that the Genre is formatted as (0)Blues, which kinda tells the same information twice. I didn't expect that layout when coding genre extraction. That's fixed now and should be available on next release 😄

Zeugma440 commented 1 year ago

Fix is available on today's v4.34