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: help for file analysis (Read 4553 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

help for file analysis

All mp3s from this podcast are shown in foobar2000 1.1 with length = 4 seconds each episode. File Integrity Verifier 1.1 doesn't report any error or inaccurate length, although the real track length is about 3 minutes each episode. The command "Fix VBR MP3 header" however adjusts the wrong length (though the codec profile is CBR).

What is wrong with this files so that foo_verifier can't detect the length errors? This four seconds seem to separate the episode's content from the standard trailer at each track's beginning, but e.g. Audacity shows the entire track with its complete length. I have the same situation with some other podcasts (American, French, Italian) and I would like to contact and inform the podcast producers how to avoid such flawy files so that they could produce proper episodes.

Direct download links for the last two episodes:
This is HA. Not the Jerry Springer Show.

help for file analysis

Reply #1 –
I've downloaded the first example file. It has layout like this:
  • ID3v2 tag
     
  • First MP3 stream - the intro
    • LAME CBR header (length 0:04 etc.)
         
    • MP3 data itself
  • Second MP3 stream - the real content
    • MP3 data itself
  • ID3v1 tag
If they want to concatenate MP3 streams like this, they should probably simply strip the LAME header from the intro part, that would be easiest.
Full-quoting makes you scroll past the same junk over and over.

help for file analysis

Reply #2 –
Thank you very much for your investigation, Yirkha. Never I would have been able to discover this 'layout' myself.

Now I will try to persuade the providers to change their manner how they produce their podcasts...

Robertina.
This is HA. Not the Jerry Springer Show.

help for file analysis

Reply #3 –
All right.

They probably have some script or stand-alone program to create the podcasts - first it crafts the ID3v2 tag with entered information, then appends contents of specified intro.mp3 and contents.mp3, then appends the ID3v1 tag.

So my guess is that the intro.mp3 is "wrongly" encoded (in quotes because it's inappropriate only for this specific usage). For example, the command-line LAME encoder has an option -t, which "disables writing LAME Tag" for these cases.

You can tell them that players which take this pseudo-header (hidden as an empty MP3 frame) and the total length stored it into account then naturally get confused and play only the specified initial part.
Full-quoting makes you scroll past the same junk over and over.

help for file analysis

Reply #4 –
I think that your explanation also answers the question why I had a strange display situation with two of the podcasts in their comment tags:



So thank you again for your help.
This is HA. Not the Jerry Springer Show.

help for file analysis

Reply #5 –
Hmm but there was only a single ID3v2 tag. Where does that screenshot come from? It seems like might have been wrongly formatted during the drawing only.

My guess: There are a bunch of newline markers used in the wild - CR, LF, or both CR+LF, tied to the originating operating system or environment. If the rendering element expected it the Windows way, i.e. both "Carriage Return" and "Line Feed" characters, but the comment field contained a single CR only, it could have returned to the beginning of the current line only and draw the second one over the existing text.
Full-quoting makes you scroll past the same junk over and over.

help for file analysis

Reply #6 –
Quote from: Yirkha on
Where does that screenshot come from?

From two episodes of that podcast (file size around 1,5 MB max each):I copied the comment's field content into my text editor and I saw something which looked like control characters for me but I was not able to identify what function they should have...

Edit: I should add that I am using Columns UI, I didn't check how the default user interface would show them.
This is HA. Not the Jerry Springer Show.

help for file analysis

Reply #7 –
Hmm, by a quick look, there don't appear to be any weird control characters, only CR/LF line endings and some TABs.
%comment% displayed in Default UI in Playlist View context had them all replaced with underscores, I did not see any glitch.
Full-quoting makes you scroll past the same junk over and over.

help for file analysis

Reply #8 –
Sorry for my misinformation, you are right, those control characters have been in one of the other podcasts mentioned above  .

In both CUI and DUI I am using the font Tahoma 8pt, but it is only Columns UI which shows that odd text overlay in its Item properties panel. However if I remove all TABs in the comment field the display is as expected. So I think I should report that in the Columns UI thread.

Thank you again for your kind support.

Robertina.
This is HA. Not the Jerry Springer Show.