Opened 16 years ago
Closed 16 years ago
#1001 closed defect (wontfix)
decoding mp3 pads audio and causes desync
| Reported by: | Owned by: | ||
|---|---|---|---|
| Priority: | normal | Component: | ad |
| Version: | HEAD | Severity: | normal |
| Keywords: | Cc: | ||
| Blocked By: | Blocking: | ||
| Reproduced by developer: | no | Analyzed by developer: | no |
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.
Note:
See TracTickets
for help on using tickets.
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