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: LAME digital silence (Read 2758 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

LAME digital silence

I seem to have a problem with the digital-silence frames produced by LAME for CBR files.

In both of my hardware mp3 players (a RCA Lyra PDP2850 and a Panasonic SL-MP70) files of this type produce a short but decidedly unpleasant blast of white noise at the end of the track.

This only occurs for CBR files (and the only examples I have are at 192kbs).

Examining the offending frames shows their structure to be as follows:

[4-byte header]
[32-byte pattern, eg. 0xFF8FF00000678000000000000CF00000000000019E00000000000033C0000000]
[some bytes of repetitive values, eg. 0x5555. Number of bytes is variable, related to bitrate?]
[string, "LAMEn.nn"]
[repetitive values until end of frame].

This appears similar to the LAME-extension to a XING/INFO header, without the XING part.

Removing these frames and replacing them with the digital silence produced using mp3Trim causes the files to be decoded correctly (ie. no blast of white noise).

Now, mp3Trim's silent frames look like this:

[4-byte header]
[32-bytes of '0']
[Repeat of 0xFFFF until end of frame].

It is my assumption (yes, I know...) that the decoder interprets any frame with 32-bytes of '0' following the header as a XING/INFO header and decodes it to silence. The frames causing my problem don't have this signature and so the decoder tries to render them as audio. Ouch.

This assumption is bourne out by zeroing bytes 5-38 of the 'bad' frames.
The file now decodes correctly.

I have automated the process by modifying the 'tidymp3' utility;
If the string 'LAME' occurs in a frame then bytes 5-38 are zeroed.
In this way correct XING/INFO/LAME headers are not affected, since in these frames those bytes are already zero.

The modified files play correctly in my hardware and software players.
No errors are found using 'mp3utility', 'mp3fixer' and 'mp3Trim'.
mp3Trim still autodetects the same amount of digital silence as it does with the original file.

Whether the LAME silent-frames are broken or not is moot; they don't decode properly in my hardware players which I am unable to modify.

The solution detailed solves my problem and I provide it here in case it is useful to anyone else.
TidyMp3 Mod/1
Comments, criticism and corrections are welcomed.

Incidentally, I remember reading somewhere on HA, advice not to use tidymp3 since it would
remove the LAME header info. It doesn't. The LAME header is contained within a valid frame and
so is left untouched.

Yatsura.