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 introduces an hidden peak at beginning and/or end ? (Read 6804 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

lame introduces an hidden peak at beginning and/or end ?

In order to listen mp3 files in my car, I usually encode with "lame -V 0" syntax. But on my last encoding, I heard clipping at beginning of one track whereas it didn't occurs at all with software players...

So I searched where it comes from, then found with mp3directcut that I can actually see a peak which didn't exist before:
- src320_10s.gif (src320_10s.mp3)
- V0-3984.gif (V0-3984.mp3)
- V0-399b0.gif
(same result with both lastest stable or beta)

When cutting the first frame with mptrim, clipping suddenly appears also with software players:
- V0-3984_trim1frame.mp3
- V0-3984_trim1frame.gif
- V0-3984_waves.gif

In fact, I can see these peaks with mp3directcut on almost all my files encoded by lame, at beginning and/or end, but they weren't played until now. Sometimes clipping appears when cutting 1 frame or more, sometimes not.

I know that clipping may occur on loud parts, but don't understand why encoding makes peaks at beginning/end while it was nearly silent !
Any idea/option in order to avoid these effect when using lame ?

lame introduces an hidden peak at beginning and/or end ?

Reply #1 –
What player is that?  It looks like the decoder glitched pretty bad for a one iteration of the filterbank.

lame introduces an hidden peak at beginning and/or end ?

Reply #2 –
First clipping was only heard on my car player (Volkswagen RCD 300).
When I trimmed the first frame, all my software players show the peak : VLC MPC-HD WMP9 WinAmp2...

lame introduces an hidden peak at beginning and/or end ?

Reply #3 –
Quote from: Dev8 on
When I trimmed the first frame, all my software players show the peak : VLC MPC-HD WMP9 WinAmp2...


Ah ok.  Then it sounds like whatever you trimmed the files with corrupted the start of the stream.

lame introduces an hidden peak at beginning and/or end ?

Reply #4 –
Quote from: saratoga on
Ah ok.  Then it sounds like whatever you trimmed the files with corrupted the start of the stream.

Then the file has been corrupted by encoding with the last stable version of lame then cut with mptrim ?
It's strange: V0-3984_waves.gif suggests that the peak is not at the very start...

In fact, trimming only reveals that the peak was already here -- I heard it with my car player.
So lame seems to produce peaks (although beginning/end were nearly silent), and players filter them ?

lame introduces an hidden peak at beginning and/or end ?

Reply #5 –
Quote from: Dev8 on
So lame seems to produce peaks (although beginning/end were nearly silent), and players filter them ?


No, more likely whatever you trimmed the files with corrupted the start of the stream.

lame introduces an hidden peak at beginning and/or end ?

Reply #6 –
mp3directcut probably causes the problem. Its approach to cutting is quite poor.

lame introduces an hidden peak at beginning and/or end ?

Reply #7 –
Quote from: saratoga on
No, more likely whatever you trimmed the files with corrupted the start of the stream.

Indeed, this could be an explanation for V0-3984_waves.gif
But in my car the clipping already occurs on a track which was only re-encoded with lame, not trimmed.
At least I agree that the car player may be involved, as a very simple mp3 player...

Quote from: Canar on
mp3directcut probably causes the problem. Its approach to cutting is quite poor.

I never cutted with mp3directcut, I used it only to see peaks.

lame introduces an hidden peak at beginning and/or end ?

Reply #8 –
mp3DirectCut is not showing you peaks. It's showing you each frame's global gain, which is like its volume knob. Generally this does roughly correspond with amplitude of the decoded audio, but not always, which is why silence sometimes looks like something loud in the GUI.

Anyway, I see two possibilities:
1. mpTrim is messing up the VBR header frame and/or the first frame after the cut,
and/or
2. your car's player simply doesn't cope well with trimmed streams.

mpTrim does the same thing as mp3DirectCut, just cutting off physical frames without much regard for what's in them, so if the bit reservoir is used, the first frame after a cut will probably be undecodable, its audio data having begun in a previous frame. This is normally not too much of a problem; we're talking about 26 milliseconds of audio being skipped by most players. Who knows what your car player is doing when it encounters such frames, but maybe it is trying to make use of the incomplete data somehow, and the result is what you are mistakenly calling "clipping". (I think you mean you hear a brief noise at the start of the track? Clipping is something else, something you'd hear as a sort of effect on the loudest parts of the music.)

Before investigating or speculating further, let me ask you something. Are you transcoding, and thus reducing quality, of LAME CBR 320 files to LAME VBR -V0 files? And then you are trimming them after that? If saving some space is the goal of the transcoding, you may want to consider using [a href='index.php?showtopic=32379']MP3packer[/a] (with the -z option) on your CBR files to squeeze them down and make them VBR without reducing quality. If you feel there's too much silence on the ends, trimming frames of silence is generally safe, as long as you leave one or two frames of silence as a buffer against the bit reservoir issue I described above. Ideally, though, before trimming, use MP3packer to repack to 320 kbps with minimal bit reservoir use (the -r option), then repack to conserve space again with -z.

lame introduces an hidden peak at beginning and/or end ?

Reply #9 –
Quote from: mjb2006 on
mp3DirectCut is not showing you peaks. It's showing you each frame's global gain, which is like its volume knob. Generally this does roughly correspond with amplitude of the decoded audio, but not always, which is why silence sometimes looks like something loud in the GUI.
Ok, so I was wrong about "hidden peaks" introduced at beginning/end by lame.

Quote from: mjb2006 on
2. your car's player simply doesn't cope well with trimmed streams.
[...]
Who knows what your car player is doing when it encounters such frames, but maybe it is trying to make use of the incomplete data somehow
At first, I heard "clipping" in my car on a file which was not trimmed. With software players it was Ok, until I tried to trim a little. But I realize that I have not tried to listen the CBR320 version in my car : maybe "clipping" also occurs...

Quote from: mjb2006 on
and the result is what you are mistakenly calling "clipping". (I think you mean you hear a brief noise at the start of the track? Clipping is something else, something you'd hear as a sort of effect on the loudest parts of the music.)
Yes, this is a brief noise a the start of the track.

Quote from: mjb2006 on
If saving some space is the goal of the transcoding, you may want to consider using [a href='index.php?showtopic=32379']MP3packer[/a] (with the -z option) on your CBR files to squeeze them down and make them VBR without reducing quality. Ideally, though, before trimming, use MP3packer to repack to 320 kbps with minimal bit reservoir use (the -r option), then repack to conserve space again with -z.
Thanks, seems really a better solution in order to reduce size.

lame introduces an hidden peak at beginning and/or end ?

Reply #10 –
Lame VBR files contain a special VBR header - players that don't understand it should interpret it as a silent mp3 frame. Maybe for some reason your car player doesn't see it as "silent"?

Just guessing.

Cheers,
David.