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: Is "decoded length" issues etc. expected to change upon rewriting tagtype? (Read 1381 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Is "decoded length" issues etc. expected to change upon rewriting tagtype?

I just went over my mp3s and made tagtypes uniform (id3v1 & id3v2.3 - no more id3v2.4), and paranoid as I am, I ran the verifier before and after. Some behaviour I had not expected, all orders are "before" before "after":

tr1 - problem "disappears":
Warning: Reported length is inaccurate : 0:55.968413 vs 0:55.994535 decoded
No problems found.

tr2 - decoded length changes:
Warning: Reported length is inaccurate : 4:24.059841 vs 4:24.007596 decoded
Warning: Reported length is inaccurate : 4:24.059841 vs 4:24.033719 decoded

tr3 - both reported and decoded lengths change
Warning: Reported length is inaccurate : 3:08.017392 vs 3:08.226372 decoded
Warning: Reported length is inaccurate : 3:08.043515 vs 3:08.252494 decoded

tr4 - reported length changes, and an apparent stream error introduced. Notice though, that the file is 2998400 bytes, so it is at the very end
Warning: Reported length is inaccurate : 3:07.233719 vs 3:07.677800 decoded
Warning: Reported length is inaccurate : 3:07.259841 vs 3:07.677800 decoded
Error: MPEG stream error at 2998329 bytes

tr5 - lengths do not change, but a second apparent stream error is introduce, also at the end; the file is 9445504
Warning: Reported length is inaccurate : 6:35.440000 vs 6:35.312086 decoded
Error: MPEG stream error at 9444364 bytes
Warning: Reported length is inaccurate : 6:35.440000 vs 6:35.312086 decoded
Error: MPEG stream error at 9444364 bytes
Error: MPEG stream error at 9445451 bytes

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #1 –
I'd only be concerned if I couldn't fix it with Utilities/Fix VBR mp3 header / Rebuild mp3 stream.

And I know it's not any of my business but.... why v1??? I could understand using it in conjunction with 2.4 but with 2.3 seems overkill. I mean how many ancient players do you need to support? :P

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #2 –
Quote from: marc2003 on
I'd only be concerned if I couldn't fix it with Utilities/Fix VBR mp3 header / Rebuild mp3 stream.
If there is something genuinely wrong, then that would only disguise the problem. A corrupted frame will be dropped or interpolated, and a valid mp3 with the corrupted audio will be written. And gapless information could be gone.

Quote from: marc2003 on
[...]how many ancient players do you need to support? :P
Precisely one: namely, my car stereo.

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #3 –
Someone may correct me if I'm wrong but I don't think anyone has ever posted anything about audible issues after using those Utility items I mentioned.

I always verify mp3s after downloading and while I often see inaccurate length reports for mp3s encoded with an unknown tool, I've never seen it with LAME encoded mp3s. I figure the mp3s with errors probably don't have useful gapless info in them.

Ultimately if you want guaranteed error free mp3s, you encode them yourself. Anything you download, including from amazon, will be subject to these sort of niggles.

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #4 –
Have you checked your tags for the presence of LAME header? iTunSMPB comment field in ID3v2 tag? Are any of them changing across tag rewrites? It sounds like one of the possible gapless encoding tags is getting rewritten with different values, causing length changes.

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #5 –
Thanks for reporting the issue.

It would be good to have these files available to look into to see what exactly happened, if you could upload a sample somewhere and send me a link via private message.

What you are seeing is most certainly neither normal nor expected and needs to be looked into.
Microsoft Windows: We can't script here, this is bat country.

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #6 –
Peter:  You got PM (edit: two PMs) with all five files.

kode54:
Peter will sure find out, but for my information: is this something I would find with mp3tag or using ffmpeg -i (which reports one of the files to use LAME, like fb2k does, but nothing more)?
 

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #7 –
Good find, thanks for reporting.

Looks like these files got their last MPEG frames clobbered by tags; the tool actually to blame for this is either the encoder or a previously used tagger.

So, here's what happens-
Before removal of the tags, foobar2000 scans for the last apparent MP3 frame, finds a valid header but doesn't notice that the frame overlaps with the tags, and decodes it - though decoding produces nonsense as the payload is malformed. This also affects detection of MP3 stream duration.
After removal of the tags, foobar2000 rejects the last frame entirely as its signaled size exceeds the file size, hence shorter decoded duration.

You can recreate the same scenario by chopping the file using a hex editor, from the first "APETAGEX" up.

I'm fixing this to prevent future confusion, editing tags should never affect decoded or reported duration, and we should not read into bad data if it can be trivially detected.

tl;dr
Nothing got lost, the data that foobar2000 no longer tries to decode was bad already, editing tags with foobar2000 is safe.
Microsoft Windows: We can't script here, this is bat country.

Re: Is "decoded length" issues etc. expected to change upon rewriting tagtype?

Reply #8 –
You are welcome. I sometimes wonder whether all these flaws could have been avoided had the mp3 file format been properly designed from the outset, or whether it is inevitable from the ubiquity of mp3 that all sorts of nonsense are to be found in the wild.