From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from uq.net.au(fox.uq.net.au[203.101.255.1]) (1682 bytes) by braille.uwo.ca via smail with P:esmtp/D:aliases/T:pipe (sender: ) id for ; Thu, 1 Mar 2001 07:33:33 -0500 (EST) (Smail-3.2.0.102 1998-Aug-2 #2 built 1999-Sep-5) Received: from data.home (mail@dyn-11-51.dialin.uq.net.au [203.100.11.51]) by uq.net.au (8.9.3/8.9.3) with ESMTP id WAA03597 for ; Thu, 1 Mar 2001 22:33:31 +1000 (GMT+1000) Received: from geoff by data.home with local-esmtp (Exim 3.12 #1 (Debian)) id 14YNBu-0005UM-00; Thu, 01 Mar 2001 17:07:58 +1000 Date: Thu, 1 Mar 2001 17:07:58 +1000 (EST) From: Geoff Shang To: Subject: Re: unexpected trplayer behavior In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Id: Hi: Your problem is definitely something for Matt Campbell to comment on. As to bit rate, this *should* always be bandwidth/data rate. In theory at least, the figure reported by the B command should always be the same for locally stored readmedia files and non-VBR MP3 files. I've not tried VBR MP3 files so I'd be interested to know what people find happens with them. I do know that trplayer reports 24.0kbps for 20kbps MP3 files, both streaming and not. Anyway, the B command should also return the same measurement when listening to an MP3 stream. If you're listening to a realmedia stream via a realserver, the number may well change (along with the quality) as the server will try to compensate for fluctuations in bandwidth, etc. Note here that the stream you actually receive is in fact changing, which is why the measurement changes. Geoff.