It seems to be quite common to use the prefix "K" to refer to multiples of
1024, and "k" for mutliples of 1000, but I don't know if this is formalised
anywhere. Similarly "B" for bytes and "b" for bits... 64KB of memory vs.
64kbps MP3.
K is used for both multiples of 1000 and 1024. 1024 is
David Balazic wrote:
Matthew Lloyd wrote:
[ big snip ]
About the differences between Nitrane and other:
Did you try to compare the sound to the original ?
Maybe you could figure out that way where that
spectral components should be.
And you forgot to test mpg123 !
( and xaudio
From: "Taupter" [EMAIL PROTECTED]
[...] the right case for multipliers is uppercase (K, M), [...]
ITYM all multipliers except k - kHz, km, etc.
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hi, all.
I also tested differences of outputs from some decoders.
Output of mpg123 is almost identical to fraunhofer's, but
there are some mp3 files whose outputs have quite large
difference.
I made a mp3 file by adding a patch to lame so that lame
randomly selects block type, and
Mathew Hendry wrote:
From: "Taupter" [EMAIL PROTECTED]
[...] the right case for multipliers is uppercase (K, M), [...]
ITYM all multipliers except k - kHz, km, etc.
No. Surely KHz, Km, et cetera el al.
Taupter
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Taupter wrote:
Mathew Hendry wrote:
From: "Taupter" [EMAIL PROTECTED]
[...] the right case for multipliers is uppercase (K, M), [...]
ITYM all multipliers except k - kHz, km, etc.
No. Surely KHz, Km, et cetera el al.
You're joking, right ?
kilo is 'k' , at least by SI ( the
From: Taupter [mailto:[EMAIL PROTECTED]]
Mathew Hendry wrote:
From: "Taupter" [EMAIL PROTECTED]
[...] the right case for multipliers is uppercase (K, M), [...]
ITYM all multipliers except k - kHz, km, etc.
No. Surely KHz, Km, et cetera el al.
Nope, however sensible that
Taupter wrote:
The term Kbps to represent data transfer speed in bits is absolutely
wrong, as bit is "bit", and Kbps is K (1000 or 1024) * byte * p (?) * s
(second). The right way could be Kbit/s. The term Kbps is widely used,
but it not a "canonical" representation.
Are you _sure_ that
Zia Mazhar wrote:
Taupter wrote:
The term Kbps to represent data transfer speed in bits is absolutely
wrong, as bit is "bit", and Kbps is K (1000 or 1024) * byte * p (?) * s
(second). The right way could be Kbit/s. The term Kbps is widely used,
but it not a "canonical"
About kbps kbit/s and more :
ftp://ftp.informatik.uni-erlangen.de/pub/doc/ISO/information-units
Perhaps we can now end this discussion and accept kbps AND kbit/s
as understandable units for '10^3bit per second' and go on to other
more LAME-related questions ...
A+
Christian
--
MP3 ENCODER
You can take the "p" as 1/x. Here x is s, so
kbps and kbit/s means the same.
Yes, and could also be written :
kbs (exponent: minus one)
From rules used in biochemistry. (same rules?)
But in a book or Word, not in a mail
Roger
-
--
MP3 ENCODER mailing list (
Using Lame 3.70 I saw that it accepts a strange thing:
using an highpass freq higher than the lowpass one
Of course the result is pure silent.
Regards,
--
Gabriel Bouvigne - France
www.mp3-tech.org
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
With the 3.80n-binary i get a lot of
informative message: drain_pre/post: wasting bits= especially with -V 2
and -V 1 combined with -B 320 or -V 0 alone, is this important or is it just a
message that hasent been removed ?
Peter
It's definately not frmalised - think about the next step up - Mega which
is prefixed by a capital M, while the lower case m represents the prefix
'mili'
Scott Manley (aka Szyzyg) /-- _@/ Mail -\
___ _ _ __ __ _ | Armagh
Gabriel Bouvigne wrote:
Using Lame 3.70 I saw that it accepts a strange thing:
using an highpass freq higher than the lowpass one
Of course the result is pure silent.
...a good check that filters work OK :-)
Pierre Hugonnet
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Hi all,
Does lame implement side channel starving? If not, I'll volunteer :-)
Ciao,
Segher Boessenkool
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Howdy All,
I recently finished completely overhauling the ISO 'dist10' LSF decoder to
extract a layer-III only player for work. In the process, I discovered a
few bugs/inconsistencies in/between the 'dist10' distribution and ISO/IEC
11172-3 and 13818-3. I don't know if they would account for
I was pretty excited to get lame 3.70 since the older releases crashed
my box. :)
I encoded an album with lame -v -h -p -b 128 (using the notlame binary)
and everything went well until I tried to play it back with mpg123...
Here's what I got:
Playing MPEG stream from
Howdy All,
I recently finished completely overhauling the ISO 'dist10' LSF decoder to
extract a layer-III only player for work. In the process, I discovered a
few bugs/inconsistencies in/between the 'dist10' distribution and ISO/IEC
11172-3 and 13818-3. I don't know if they would
Hi all,
Does lame implement side channel starving? If not, I'll volunteer :-)
Ciao,
Segher Boessenkool
LAME has crude algorithm which allocates bits based on
the energy contained in the side channel vs. mid channel.
It definatly needs work: I have some test cases where LAME
With the 3.80n-binary i get a lot of " informative message:
drain_pre/post: wasting bits=" especially with -V 2 and -V 1
combined with -B 320 or -V 0 alone, is this important or is it just
a message that hasent been removed ?
Peter
It just hasn't been removed. It tells how many
Thanks for the summary, Mark.
I forgot to mention the 330/332 bug, which I had independently located and
saw discussed here earlier. I looked at the ISO code for the Huffman
quadruples, and it looks OK. There is very little scfsi related code, and
it looks OK, though I don't think I've ever
Mark Taylor schrieb am Don, 20 Apr 2000:
With the 3.80n-binary i get a lot of " informative message:
drain_pre/post: wasting bits=" especially with -V 2 and -V 1
combined with -B 320 or -V 0 alone, is this important or is it just
a message that hasent been removed ?
Peter
23 matches
Mail list logo
