Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Missing mp3 tags (Read 3301 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Missing mp3 tags

I recently downloaded FooBar2000 v 1.1.13 and like it very much. It works well with my FLAC files. I tried to import my mp3 files (over 10,000 files) and found several thousand apparently did not have meta-data. On investigation, it appears that the programs which originally wrote the mp3 files wrote tag info into the v1 tags and then included empty v2 tags. However, when FooBar2000 reads the files it doesn't see the v1 tag info because the empty tags are seen first. That causes the mp3 files to not be categorized properly. Most other programs read the data ok (Mp3Tag is an exception, I have submitted a bug report to them as well). In particular, Windows Explorer, RealPlayer and Zune have no problem. I am using Windows XP (and would really like it to run on my Windows 2000 machines).

Missing mp3 tags

Reply #1 –
Quote from: Dragonne on
I recently downloaded FooBar2000 v 1.1.13 and like it very much. It works well with my FLAC files. I tried to import my mp3 files (over 10,000 files) and found several thousand apparently did not have meta-data. On investigation, it appears that the programs which originally wrote the mp3 files wrote tag info into the v1 tags and then included empty v2 tags. However, when FooBar2000 reads the files it doesn't see the v1 tag info because the empty tags are seen first. That causes the mp3 files to not be categorized properly. Most other programs read the data ok (Mp3Tag is an exception, I have submitted a bug report to them as well). In particular, Windows Explorer, RealPlayer and Zune have no problem. I am using Windows XP (and would really like it to run on my Windows 2000 machines).


pull all these files into mp3tag.  use the options to set it to read v1 and v2 files but write only v2 files.  Then you can delete the v1 tags and end up with all mp3 files with only v2 tags containing all your metadata.  There are several posts on mp3tag forum regarding how to do this.

Missing mp3 tags

Reply #2 –
Quote from: Dragonne on
I recently downloaded FooBar2000 v 1.1.13 and like it very much. [...] I am using Windows XP (and would really like it to run on my Windows 2000 machines).

foobar2000 dropped Windows 2000 support in version 0.9.5. There have been many changes since then, so some of the features you like in the current version may not be available in 0.9.4.5, the last version you can use on Win2K.

Missing mp3 tags

Reply #3 –
Quote from: garym on
Quote from: Dragonne on
I recently downloaded FooBar2000 v 1.1.13 and like it very much. It works well with my FLAC files. I tried to import my mp3 files (over 10,000 files) and found several thousand apparently did not have meta-data. On investigation, it appears that the programs which originally wrote the mp3 files wrote tag info into the v1 tags and then included empty v2 tags. However, when FooBar2000 reads the files it doesn't see the v1 tag info because the empty tags are seen first. That causes the mp3 files to not be categorized properly. Most other programs read the data ok (Mp3Tag is an exception, I have submitted a bug report to them as well). In particular, Windows Explorer, RealPlayer and Zune have no problem. I am using Windows XP (and would really like it to run on my Windows 2000 machines).


pull all these files into mp3tag.  use the options to set it to read v1 and v2 files but write only v2 files.  Then you can delete the v1 tags and end up with all mp3 files with only v2 tags containing all your metadata.  There are several posts on mp3tag forum regarding how to do this.


There are several problems with this. First is the sheer effort since these files are interspersed amoung a large number of other files. They are not clearly identified. The second problem is that Mp3Tag also fails when reading these files (as my original post stated). Finally, I would have to repeat the procedure every time another one of these files appears. I don't actually know which program is generating them. The best solution is to treat any empty tag as if it doesn't exist. A minor code fix.

Missing mp3 tags

Reply #4 –
Quote from: Dragonne on
I don't actually know which program is generating them.


You might want to explain why this isn't due to your grabbing those files off an illegal filesharing network. If people believe that you got it from a legitimate source, they might be more likely to help.

Missing mp3 tags

Reply #5 –
I own every single CD that I have ripped and I have never downloaed ANY file illegally. And I have never installed ANY file sharing program. I value my security way too much to do something stupid like that.

I don't know which program wrote the files without looking in the binary because I have been ripping my CD collection for well over 10 years (and I started collecting CDs the first year that they came out) and have used multiple programs and multiple versions of the programs. Most, but not all, were ripped by various  versions of Real JukeBox and Real Player. I still have Real JukeBox on one Windows 2000 machine and have the most recent Real Player on another. I recently started an effort to rerip everything using dbPoweramp as FLAC files. It has been two years and I still have at least one (large) box of CDs to go. Eventually, I will replace all of my .mp3 files with .flac files but I don't yet have a player that can handle 300 or 400G of .flac files (I know that COWON makes one, which I might eventually get). Right now I use a 120G Zune which handles all of the .mp3 files.

In the interrim, I currently rip a new CD with dbPoweramp for the long-term .flac collection and then rip it again with Real Player for immediate usage. Once I make the transition, all .mp3 files will be deleted. The highly accurate .flac ripping option was not available when I started ripping. My .flac ripping machine has 3 CD drives, one of which can read inter-gap. My .mp3 ripping machine only has a single drive, but Real Player doesn't cooperate well with the multiple drives.

My goal in using this program is to eliminate Real Player except for ripping. It works very nicely with my .flac files and the only issue is the problem with .mp3 tags.

I have been discussing the same issue on the Mp3Tag forum. Apparently what is happening there, and perhaps here, is that first if there are any APE tags then only APE tags are used. If there are no APE tags and there are any ID3V2 then only ID3V2 tags are used. If there are neither APE nor ID3V2 tags then and only then will ID3V1 tags be used.

In general, the idea that APE first then ID3V2 then ID3V1 is ok. However, that decision should be made on a tag-by-tag basis. And a tag which is blank or missing should not "hide" a lower level tag of the same type. So if there is an Artist ID3V2 tag which is non-blank then it should be used. But, at the saem time if the Title ID3V2 tag is blank or missing then then ID3V1 tag should be used. That is basic data robustness.

It is alo possible that Real JukeBox stored some of the ID3V2 tag data in a "geneic" tag that only it understands. Or at least only it and Microsoft Zune. That tag data should be completely ignored if it is not understandable and ID3V1 data used instead. Again basic data robustness.

Missing mp3 tags

Reply #6 –
Quote from: Dragonne on
In the interrim, I currently rip a new CD with dbPoweramp for the long-term .flac collection and then rip it again with Real Player for immediate usage.

... but why do that, when you can just encode .mp3's from your .flac's?

(I know that this was not your original question.)

Missing mp3 tags

Reply #7 –
Quote from: Dragonne on
...

In general, the idea that APE first then ID3V2 then ID3V1 is ok. However, that decision should be made on a tag-by-tag basis. And a tag which is blank or missing should not "hide" a lower level tag of the same type. So if there is an Artist ID3V2 tag which is non-blank then it should be used. But, at the saem time if the Title ID3V2 tag is blank or missing then then ID3V1 tag should be used. That is basic data robustness.

...


What you're suggesting would make tag parsing needlessly complex and more prone to bugs IMO. foobar would have to look for a set of possible frames and compare them according to their content size only(<I assume that's what you mean by "data robustness") then return that frame which contains the most data. That might be okay if every single frame contains the correct data, but what if a frame (or a set of frames) for whatever reason contains nothing but gibberish while another frame smaller in size contains the correct data?

There are drawbacks to every "good idea" we think we have. A solution to one problem always opens the doors to others leading to ever increasing complexity. I don't think foobar needs to become a Rube Goldberg machine in its tag reading and writing when basic human monitoring will suffice.

Missing mp3 tags

Reply #8 –
Quote from: Porcus on
Quote from: Dragonne on
In the interrim, I currently rip a new CD with dbPoweramp for the long-term .flac collection and then rip it again with Real Player for immediate usage.

... but why do that, when you can just encode .mp3's from your .flac's?

(I know that this was not your original question.)


I will, eventually, once I have finished ripping. Right now the .flac collection is incomplete and will remain so for probably another year. In the meantime, the .mp3 collection is complete and is concurrently maintained until I can switch over.

Missing mp3 tags

Reply #9 –
Quote from: BenB on
Quote from: Dragonne on
...

In general, the idea that APE first then ID3V2 then ID3V1 is ok. However, that decision should be made on a tag-by-tag basis. And a tag which is blank or missing should not "hide" a lower level tag of the same type. So if there is an Artist ID3V2 tag which is non-blank then it should be used. But, at the saem time if the Title ID3V2 tag is blank or missing then then ID3V1 tag should be used. That is basic data robustness.

...


What you're suggesting would make tag parsing needlessly complex and more prone to bugs IMO. foobar would have to look for a set of possible frames and compare them according to their content size only(<I assume that's what you mean by "data robustness") then return that frame which contains the most data. That might be okay if every single frame contains the correct data, but what if a frame (or a set of frames) for whatever reason contains nothing but gibberish while another frame smaller in size contains the correct data?

There are drawbacks to every "good idea" we think we have. A solution to one problem always opens the doors to others leading to ever increasing complexity. I don't think foobar needs to become a Rube Goldberg machine in its tag reading and writing when basic human monitoring will suffice.


It is not anythling as complex as you are making it sound. Foorbar must already check for the tags, presumably it checks for APE, then for ID3V2 and then ID3V1 (f it is like Mp3Tag). Once it finds a block of tags it must iterate through the tags adding them to its collection of "found" tags.

All I am suggesting is

1) Don't stop looking at the first block of tags that are found. Process each block in its priority order as is currently done.

2) When adding a tag to the collection, do not add the tag if a) it is blank or b) a tag of the same type is already present in the collection.

The above is very simple and robust and shouldn't require any major changes. The find loop is the same, the exiit from the loop is different. The processing of a blcok should be almost the same except for the two exclusions mentioned above.

You do NOT need to compare tags by size or anything like that. The issue isn't trying to pick up the longest tag -- and who is to say that is the "correct" tag? The issue is to pick up tags with ANY data and ignoring tags with NO data. If the tag is garbage, it is garbage. That is still data. Blanks or omission do not constitute data.

I am assuming that the existing pseudo code is something like this...

...tags <= new Map<String,String>
...for each tagBlock order by "APE', 'ID3V2", "ID3V1"
......for each tag in tagBlock
.........tags.add(tagName, value)
......break

And that it should be modified as follows...

...tags <- new Map<String,String>
...for each tagBlock order by "APE', 'ID3V2", "ID3V1"
......for each tag in tagBlock
.........if value.Trim() != "" and not tags.contains(tagName)
............tags.add(tagName, value)

Sorry for the leading dots, but the post destroys indentation.

This is very simple, robust and allows all possible tag data to be retrieved. The only change is to remove a "break" and add a simple condition. If a file contains a higher level tag type which contains all of the possible tag names then there is no difference. If a lower level tag block contains tag names not present in a higher level tag block then this change is far preferrable because it picks up more tag data. And is certainly the expected behaviour regardless of the amount of effort.

Missing mp3 tags

Reply #10 –
Quote
Sorry for the leading dots, but the post destroys indentation.
You can use code tags to preserve leading and/or sequential spaces in a fixed-width font. Or, alternatively, you can use standard text and the greater range of formatting it allows, while still being able to indent, by replacing any relevant standard space with a hard space such as the Japanese one.

Missing mp3 tags

Reply #11 –
Quote from: Dragonne on
Quote from: Porcus on
Quote from: Dragonne on
In the interrim, I currently rip a new CD with dbPoweramp for the long-term .flac collection and then rip it again with Real Player for immediate usage.

... but why do that, when you can just encode .mp3's from your .flac's?

(I know that this was not your original question.)


I will, eventually, once I have finished ripping. Right now the .flac collection is incomplete and will remain so for probably another year. In the meantime, the .mp3 collection is complete and is concurrently maintained until I can switch over.


Yes but still: why 'rip again with Real'? What's the use?

Missing mp3 tags

Reply #12 –
As I have re-ripped into .flac files, I have also changed classifications and file organization - sometimes signficantly (benefits of hindsight). Also, where I usually merge multi-cd albums into one for the .flac, that is not always appropirate for the .mp3 collection (some versions of Real don't like 4 digit track numbers and I have 692 tracks for one album - a book). I could convert the ripped .flac into .mp3 using lame as an extra step. However, ripping using Real is actually much faster. So more a matter of convenience. None of that is relevant to this problem, other than a matter of curiosity.
 

Missing mp3 tags

Reply #13 –
And "this problem" is where the two of us disagree. I see the solution as you correcting your broken tags while you seemingly see it as foobar ignoring your broken tags. I prefer foobar return these tags so that I can fix them rather than have foobar hide them from me.