Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Gabriel Bouvigne
> I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. > does someone donate me a machine or shell account :-) ? 3D now and SSE are fine, but why not some MMX code? A lot more people got mmx processors. Are 3D Now and SSE really faster than MMX? > and these have not written

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Ross Levis
I can only say keep up the good work Takehiro :). It wouldn't be the same without you! Ross. Takehiro Tominaga wrote: > Hi all. > > I'm planning these features to merge the current LAME from my snapshot... > > 0 new bitstream handling code > (this is almost done by Mark) > > 1 new shor

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Segher Boessenkool
> > I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. > > does someone donate me a machine or shell account :-) ? > > 3D now and SSE are fine, but why not some MMX code? A lot more people > got mmx processors. Are 3D Now and SSE really faster than MMX? MMX is integer, 3dno

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Scott Manley
> > > I'm planning some 3D Now!, SSE code, but I have no K6-2/3, Athlon, PIII. > > > does someone donate me a machine or shell account :-) ? > > > > 3D now and SSE are fine, but why not some MMX code? A lot more people > > got mmx processors. Are 3D Now and SSE really faster than MMX? > > MMX is

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Ivo van Heel
> > 6 call best huffman code each iteration > > maybe very very slow, but quality will be up. > This could be called only in the highest quality setting, like in > mp3enc, when quality setting will be implemented But depending on how slow this will actually be, it maybe not always be desi

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Mark Taylor
> From: Takehiro Tominaga <[EMAIL PROTECTED]> > Date: Thu, 06 Apr 2000 20:50:25 +0900 > > Hi all. > > I'm planning these features to merge the current LAME from my snapshot... > > 0 new bitstream handling code > (this is almost done by Mark) > This is almost done. The new code works

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Gabriel Bouvigne
Mark Taylor wrote: > Other problem: what is the algorithm to determine when to use > a short block instead of a mixed block? I think (but my memory is not very sure about it) that AT&T Pac uses mixed blocks. So we may find info about them in Johnson papers or in AT&T patents (as those ones are

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Segher Boessenkool
> > > > 5 mixed_block support > > Funny you should mention that. When I was getting bitstream.c > to work in LAME, i saw that old #ifdef ALLOW_MIXED and thought > this code is never going to be used and deleted it :-) > Anyway, it is still in CVS. I dont recall evern seeing *any* encoder > mak

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-06 Thread Zia Mazhar
> But depending on how slow this will actually be, it maybe not always be > desired, so I'm not sure if this should make the difference between a > --quality 8 or --quality 9 (9 being the maximum) option, if you know what > I mean. I think a different switch should be fixed for this, like -eh [ex

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-07 Thread David Balazic
Zia Mazhar wrote: > > > But depending on how slow this will actually be, it maybe not always be > > desired, so I'm not sure if this should make the difference between a > > --quality 8 or --quality 9 (9 being the maximum) option, if you know what > > I mean. > > I think a different switch shoul

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-07 Thread Bruce Janson
From [EMAIL PROTECTED] Thu Apr 6 22:15:19 2000 .. To: [EMAIL PROTECTED] .. From: Takehiro Tominaga <[EMAIL PROTECTED]> .. I'm planning these features to merge the current LAME from my snapshot... .. 4 many ix86 assembler routine .. Takehiro, Many of us

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-07 Thread Ivo van Heel
> > > But depending on how slow this will actually be, it maybe not always be > > > desired, so I'm not sure if this should make the difference between a > > > --quality 8 or --quality 9 (9 being the maximum) option, if you know what > > > I mean. > > I think a different switch should be fixed for

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-07 Thread Takehiro Tominaga
> "S" == Segher Boessenkool <[EMAIL PROTECTED]> writes: >> Other problem: what is the algorithm to determine when to use a >> short block instead of a mixed block? S> You could try: use mixed blocks, unless there is a surge in S> energy in the lowest frequency bands. We shou

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-07 Thread Takehiro Tominaga
> "Segher" == Segher Boessenkool <[EMAIL PROTECTED]> writes: >> > I'm planning some 3D Now!, SSE code, but I have no K6-2/3, >> Athlon, PIII. > does someone donate me a machine or shell >> account :-) ? >> >> 3D now and SSE are fine, but why not some MMX code? A lot more

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-08 Thread Hudson Kingery
I would like to see quality as the number 1 priority, especially at higher bitrates. Ease of code improvement and maintenance as the 2nd priority. Speed as a very distant 3rd. Additional features not related to quality as 4th. Has anyone found examples of music that are not transparent at 256k or

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-09 Thread Gabriel Bouvigne
> IF there are such musical selections and given that CDRs, CDR media and > large harddrives are becoming more affordable by the day - has any > consideration been given to extending the bitrate up to 384k and 440k? Do > the ISO specs allow for this? Could these bitrates be handled by widely > av

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-09 Thread Mathew Hendry
> From: "Hudson Kingery" <[EMAIL PROTECTED]> > > Has anyone found examples of music that are not transparent at 256k or > 320k? castanets.wav and fatboy.wav on the LAME web page. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Greg Maxwell
On Sat, 8 Apr 2000, Hudson Kingery wrote: [snip] > Has anyone found examples of music that are not transparent at 256k or > 320k? I'm referring to transparent on a mid-range home stereo not a > high-end studio quality rig. (Mid-range to me is a Denon receiver and > Sennheiser 580 headphones. I do

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Mythos
huge snip > > If you are going to make an incompatible format, why not go all the way > and fix all of MP3's stupidness. > > Take a look at vorbis. > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) wich stupidness are you reffering to? -- MP3 ENCODER mailing list ( http://gee

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Mythos
huge snip > > If you are going to make an incompatible format, why not go all the way > and fix all of MP3's stupidness. > > Take a look at vorbis. > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) wich stupidness are you reffering to? -- MP3 ENCODER mailing list ( http://gee

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Jack Moffitt
> wich stupidness are you reffering to? Hahahah :) There's lots of stupid things that mp3 does. It's just an old model designed under considerations that aren't always valid anymore. Mark has said a few times that there are several rather obvious things you could change that may increase sou

RE: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Ross Levis
> Mark has said a few times that there are several rather > obvious things you > could change that may increase sound quality. Could these "things" be implemented in an MP3 encoder, or would they need a completely different format? Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encod

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Shawn Riley
At 09:13 AM 4/10/00 -0400, Greg wrote: >If you are going to make an incompatible format, why not go all the way >and fix all of MP3's stupidness. The guitarist in my band uses a Yamaha MD8S to record all our stuff. It compresses 1 CD's worth of audio down to about 150MB (about 5x compression) by

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-10 Thread Shawn Riley
Oops... At 09:13 AM 4/10/00 -0400, Greg wrote: >On some samples with mp3, 320k is not transparent to such listeners on any >sound equipment What about a mono MP3 sample at 320kBit/sec (vs a mono PCM sample at 705.6kBit/sec)? I guess that defeats the purpose of MP3, but it would be interesting t

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Adam Whitehead
CEO - Netherworld Media E-mail: [EMAIL PROTECTED] Phone: +61 (889) 279 898 FAX: +61 (889) 273 889 AudioPhilez (http://www.audiophilez.com) - Original Message - From: "Shawn Riley" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 11, 2000 4:44 PM Subj

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Christopher Wise
On Tue, 11 Apr 2000, Adam Whitehead wrote: > ATRAC is the codec used by Minidisc recorders. According to 'experts' it is > not perceptually lossless either. As far as I can remember the bitrate is > 292kbit/s > which is above what people are comfortable with transferring over the > Internet. >

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Segher Boessenkool
> > wich stupidness are you reffering to? > > > Hahahah :) > > > There's lots of stupid things that mp3 does. It's just an old model > designed under considerations that aren't always valid anymore. I don't understand this? Did the physics change, or the human ear/brain? > > Mark has said

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Jack Moffitt
> I don't understand this? Did the physics change, or the human ear/brain? No. They did not. But the research that the psychoacoustics most encoders used is most likely wrong. Monty has spent a lot of time researching psychoacoustics for vorbis, and has found lots of new research that showed t

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Ivo van Heel
> > I don't understand this? Did the physics change, or the human ear/brain? > No. They did not. But the research that the psychoacoustics most > encoders used is most likely wrong. Monty has spent a lot of time > researching psychoacoustics for vorbis, and has found lots of new research > that

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-11 Thread Jaroslav Lukesh
| Odesílatel: Adam Whitehead <[EMAIL PROTECTED]> | > The guitarist in my band uses a Yamaha MD8S to record all our stuff. It | compresses 1 CD's worth of audio down to about 150MB (about 5x compression) | by removing details from the signals that we can't hear (so I assume it | works in much the s

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-12 Thread Shawn Riley
>Sony have made a lower bitrate version called ATRAC3 that is available as >software. >http://www.world.sony.com/Electronics/ATRAC3/ > >It's used by the Sony Vaio portable music player. >According to reviews the encoder uses some encryption so that you can only >play back the files on the pc in w

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-12 Thread Shawn Riley
>Yamaha MD multitrack recorders uses slightly modified ATRAC. When you use >MD from SONY, they sound much worse than MD recorded on multitrack from >Yamaha. But standard stereo mode sounds same as SONY. Since you normally only record one instrument per track on the MD recorders, I'd expect it to

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-12 Thread Christopher Wise
On Thu, 13 Apr 2000, Shawn Riley wrote: > Okay, so I spelt it wrong too... hehehe. Hey, what's this? It can only > be played on the pc that created them? So what if a user decides to > upgrade? I don't really like the idea of ripping the same 15-or-so CDs > every few years because my new compute

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-12 Thread Shawn Riley
Yikes! So what about "SDMI-Compliant CDs"? Does that mean they'll only be able to be ripped analog? Or does it mean they'll only play in one CD player? j/k It shouldn't be too hard to make a bitwise copy of a CD though... Should it? If I was going portable, I'd much rather try the standard porta

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-13 Thread Scott Manley
> It's no joke. It's a feature of the SDMI (secure digital music > initiative). It's scary to think that in the future all portable mp3 > players may have this feature. Of course it must be even more frightening for the SDMI designers that by the time these systems get fully depolyed your aver

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-13 Thread Richard A. Smith
On Thu, 13 Apr 2000 11:32:55, Shawn Riley wrote: >Do the Minidisc players skip like CDs, or do they have a significant read-ahead or >otherwise >to get around this? I have a Sony Minidisc player that I take out on the boat with me while I am wakeboarding. It takes quite a bit of abuse but I ha

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-13 Thread Adam Whitehead
rsday, April 13, 2000 11:40 PM Subject: Re: [MP3 ENCODER] the road to next(v4.00?) > On Thu, 13 Apr 2000 11:32:55, Shawn Riley wrote: > > >Do the Minidisc players skip like CDs, or do they have a significant read-ahead or otherwise >to get around this? > > I have a Sony Minidisc

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-21 Thread Mark Stephens
Howdy, I tried to search through all the messages related to this topic, but I couldn't find any that addressed the speed issue. Trying VBR using the lastest 3.8 CVS source, VBR is still slower than CBR. Is this still a future improvement, or do I need to set an option? mark stephens - O

Re: [MP3 ENCODER] the road to next(v4.00?)

2000-04-24 Thread Mark Taylor
> > Howdy, > > I tried to search through all the messages related to this topic, but I > couldn't find any that addressed the speed issue. Trying VBR using the > lastest 3.8 CVS source, VBR is still slower than CBR. Is this still a > future improvement, or do I need to set an option? > > mark