Caster wrote:
the program musiCutter from http://macik.homepage.com to split it into mp3
files (it can import the cuesheet so you don't have to manually
find starts
and ends of mp3s) Then you can play it with winamp and some
continous output
plugin and it plays it really without gaps
Couldn't it be so that user can (with some command) determine if he wants to
remove the samples or not (or specify the number of samples he wants to
remove)? When you decode mp3's made by other encoder (or older version of
Lame perhaps), the delay is different...
Caster
It can't be solved
When you want to burn audio cd from this, just join
these mp3's
together (there's no tool for this yet, you have to cut the possible TAGs
from the files with some TAG program and then join with copy file1 + file2
musiCutter 0.5 will have this join function (will be released in a few
| "really without gaps" is not always true, because of the inter-frame
| dependencies (bit-reservoir). The only way to do it trully gapless is to
| join these mp3s before decoding, but no present player can do it
run-time. I
| can hear small pops in winamp even if using continous output, because
It's not the fade that is the problem, it's the mdct aliasing.
I disagree. There may be some problems created by the *filterbank*,
but the only attenuantion caused by the MDCT will be the first 96
samples. Here's an example:
[...SNIP...]
granule 2 is the first granule that is
vdbj wrote:
(removed long mail)
Perhaps we could add an advanced option for adjusting the encoder delay?.
I know that if reduced to the max, it will lower the quality of the
first frame, but in some cases it could be a better choice.
Regards,
--
Gabriel Bouvigne - France
Hello vdbj,
Thursday, May 18, 2000, 12:05:47 PM, you wrote:
v Hello,
v I'm no ingenieer
and also no engineer (let alone english)
v I took the liberty to quickly (don't know C) browse through the lame
v source, and I saw a larger frame size was taken compared to Xing for
v info header, so LAME
v I took the liberty to quickly (don't know C) browse through the lame
v source, and I saw a larger frame size was taken compared to Xing for
v info header, so LAME string could be included. Maybe some (extra) room
v could be utilized to store those extra few start- and stop bits?
or maybe best
vdbj wrote:
Hello Gabriel,
Thursday, May 18, 2000, 12:38:53 PM, you wrote:
GB Perhaps we could add an advanced option for adjusting the encoder delay?.
GB I know that if reduced to the max, it will lower the quality of the
GB first frame, but in some cases it could be a better choice.
What I suggest to compensate for this 'mp3 lapse':
1- (preferable): first encode the stream, then insert precise
start- and end-point into Info header (like extension to Xing VBR
one). Then a tool aquainted with this extended header would be able
to do a very accurate "--decode" (hint
10 matches
Mail list logo
