Re: [MP3 ENCODER] Another audio exciter or something more substantial?

2000-06-25 Thread Mark Taylor
> > RE: > http://www.kenwoodcorp.com/i/topframes/press_sdrive_2620.html > > Any comments? > > -- > Dmitry Boldyrev > Subband Software, Inc. > http://www.subband.com > > This just made it into slashdot. They also seem to not know what is going on, but maybe some of the feedback will

Re: [MP3 ENCODER] Block types vs frequency/time resolution

2000-06-25 Thread Shawn Riley
I wrote- >>I suspected that long blocks would also have better frequency resolution >> than short blocks (by a factor of 3). Monty wrote- >Yep, that's exactly it; better frequency resolution means better energy >compaction of strong tones so that they're generally represented in finer >resolut

Re: [MP3 ENCODER] Ogg: mostly hype and a _lot_ to be done

2000-06-25 Thread Greg Maxwell
On Sun, 25 Jun 2000, Monty wrote: > > > Eeek. Not a way to show off, Monty. I put in 3 more minutes of work beyond > > the short block hack: > > > > http://linuxpower.cx/~greg/logs.ogg > > OK, I replaced mine. But I was *just* illustrating the effect of that one bug. > I'm not *trying* to sho

Re: [MP3 ENCODER] Ogg: mostly hype and a _lot_ to be done

2000-06-25 Thread Monty
> Eeek. Not a way to show off, Monty. I put in 3 more minutes of work beyond > the short block hack: > > http://linuxpower.cx/~greg/logs.ogg OK, I replaced mine. But I was *just* illustrating the effect of that one bug. I'm not *trying* to show off... "We're all engineers here. Except for t

Re: [MP3 ENCODER] Ogg: mostly hype and a _lot_ to be done

2000-06-25 Thread Greg Maxwell
On Fri, 23 Jun 2000, Monty wrote: [snip] > For comparison purposes, here's the same sample with short blocks disabled (and > a less lossy codebook set): > > http://www.xiph.org/ogg/vorbis/test.ogg [snip] Eeek. Not a way to show off, Monty. I put in 3 more minutes of work beyond the short block

Re: [MP3 ENCODER] Block types vs frequency/time resolution

2000-06-25 Thread Monty
> Hi everyone. > Just a quick question... > > I know that short blocks require more bits to encode than long blocks, but > is that the only drawback with using short blocks? I suspected that long > blocks would also have better frequency resolution than short blocks (by a > factor of 3). Yep, th

[MP3 ENCODER] Block types vs frequency/time resolution

2000-06-25 Thread Shawn Riley
Hi everyone. Just a quick question... I know that short blocks require more bits to encode than long blocks, but is that the only drawback with using short blocks? I suspected that long blocks would also have better frequency resolution than short blocks (by a factor of 3). Thx Shawn -- MP3 ENCO

Re: [MP3 ENCODER] General ABR questions

2000-06-25 Thread Shawn Riley
Hi. I have a couple of my own questions about this. It sounds like what's being referred to as "ABR" would be not only faster, but more reliable (in quality terms) than the traditional VBR. So what's the use of traditional VBR now? Could Lame be changed to set "ABR" quality using the standard "-

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Zia Mazhar
I guess ID3v2 tag doesn't cause any conflict anywhere... Does it? Is it possible to keep both version of tags? Then, the programs which do not support v2 may read the v1 tag... But I guess that'll confuse most of the players [if not all of them!] because they probably are not specifically programm

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Scott Manley
I thinbk the point is tha in standard http streaming ,you can insert an ID3V2 tag at the start of the stream and have title data displayed - even if you're streaming static files from apacghe. Scott Manley (aka Szyzyg) /-- _@/ Mail -\ ___ _ _ __ _

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Sigbjørn Skjæret
>> Why add version 2 tags at all? Version 1 tags are virtually useless >> within streaming audio (since they don't appear until the end of the >> stream), so version 2 tag support is essential for that type of >> application. >Not really. Take a look at my streaming MP3 station on Live365 at >ht

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread highroad
Not really. Take a look at my streaming MP3 station on Live365 at http://www.live365.com/cgi-bin/directory.cgi?autostart=wtgfs and you'll see the info from the ID3 version 1 tags for all clips. The server, which of course runs much faster than the internet connection, simply reads the ID3 Version

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Don Melton
On Sun, Jun 25, 2000 at 11:33:20AM +0200, Gabriel Bouvigne wrote: > > So ... comments? Does anyone not want this feature? How about a > > different behavior? Or should I just start typing away now? :-) > > I personnally don't use the lame id3 options. But, personnally, I'd like to > have by de

Re: [MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Gabriel Bouvigne
> So ... comments? Does anyone not want this feature? How about a > different behavior? Or should I just start typing away now? :-) > I personnally don't use the lame id3 options. But, personnally, I'd like to have by default both v1 and v2 tags if v2 are necessarry (ie more than 30 char), as

[MP3 ENCODER] LAME ID3 version 2 support proposal

2000-06-25 Thread Don Melton
Gang, I have a proposal for adding ID3 version 2 tag support to LAME. Why? Well, someone asked about it on the mailing list several weeks ago and I was bored and just wanted to make a contribution again. :-) Actually, since version 2 tags are normally the first frame of an MPEG audio stream, it