search

TianyiShi2001 / audiotags

Unified IO for different types of audio metadata
https://tianyishi2001.github.io/audiotags
MIT License
39 stars 28 forks source link

NoTag: reader does not contain an id3 tag #42

Open martpie opened 6 months ago

martpie commented 6 months ago

I am getting the NoTag: reader does not contain an id3 tag trying to get the ID3 of a my library. Please tell me if it's an issue for id3 or for audiotags :)

Node.js' music-metadata can parse those with no issues.

I have put a few of those files in this drive folder in case that can help.

Serial-ATA commented 5 months ago

That error comes from id3

Serial-ATA commented 5 months ago

Your files have ID3v1 tags, and audiotags assumes ID3v2. id3 has v1v2::read_from_path to handle both if you'd like to refactor audiotags to use that.

pinkforest commented 5 months ago

Was or Is there a reason why somebody would want to read only v2 tag and not v1v2 behind abstraction - I'm wondering why there is explicit abstraction at id3 level. Sounds like it would be preferable to assume v1v2 everywhere vs v2 as of now ? EDIT: or is it just because id3 API used to support v2 only and then they perhaps added v1v2 later ?

pinkforest commented 5 months ago

I mean it does make sense for writing.. yeah so I guess reading for mp3 can use v1v2 by default ?

martpie commented 5 months ago

Thank you @Serial-ATA, let me try that :)

pinkforest commented 5 months ago

Also since Id3 doesn't support writing Id3v1 we either need to label it read-only ?

Serial-ATA commented 5 months ago

Was or Is there a reason why somebody would want to read only v2 tag and not v1v2 behind abstraction

v1v2 is a relatively new module IIRC. Definitely wasn't around back when this was made.

Also since Id3 doesn't support writing Id3v1 we either need to label it read-only ?

Well, I think it just upgrades it to an ID3v2 tag? If that's the case it should be documented, since that could be pretty surprising behavior when you write.

pinkforest commented 5 months ago

Is there possibility to lose any information in the conversion from v1 to v2 tags e.g. were any of the fields dropped and are there any incompatibility concerns otherwise e.g. where a field loses data going to v2 from v1 ?

If there are any data loss / corruption issues this sounds dicy without making this conversion explicit where the intent is clear from API perspective that it will be lossy (if any) upon write to v2 from v1 read ?

Though given there is abstraction at v1v2 at id3 already this is just an upgrade right without any loss / corruption ?

Serial-ATA commented 5 months ago

Is there possibility to lose any information in the conversion from v1 to v2 tags e.g. were any of the fields dropped and are there any incompatibility concerns otherwise e.g. where a field loses data going to v2 from v1 ?

v1 to v2 is completely lossless since v1 is so basic (only supports title, artist, album, year, comment, track number).

The only issue it would theoretically cause is someone is using an incredibly old app that doesn't understand ID3v2 tags, otherwise it's just an overall upgrade since it allows for much more future metadata expansion.