Opened 11 years ago

Closed 11 years ago

#1001 closed defect (wontfix)

decoding mp3 pads audio and causes desync

Reported by: aflist2@… Owned by: r_togni@…
Priority: normal Component: ad
Version: HEAD Severity: normal
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

hello,

<mplayer cvs r25532>

i was intending to compare quality of mp3lib/ffmp3/libmad as a decoder, when i discovered some desync issues. the full writeup and all sources, encoded, and decoded files are at the bug url.

playing a lame-encoded mp3 with mplayer pads the beginning by 47ms using mp3lib, ffmp3, and libmad.
decoding with lame does not have any desync.
using -ao pcm on the source pcm file does not have any desync and is a perfect copy.

Change History (1)

comment:1 Changed 11 years ago by reimar

  • Resolution set to wontfix
  • Status changed from new to closed

Your conclusion is wrong. lame simply clips the first samples which may be nice in some cases but in no way can be considered more correct, it can actually lead to losing samples.
See http://mp3decoders.mp3-tech.org/decoders_lame.html

Note: See TracTickets for help on using tickets.