public inbox for speakup@linux-speakup.org
 help / color / mirror / Atom feed
* unexpected trplayer behavior
@  Charles Hallenbeck
   ` Geoff Shang
  0 siblings, 1 reply; 3+ messages in thread
From: Charles Hallenbeck @  UTC (permalink / raw)
  To: Trplayer Discussions, Speakup Distribution List

My apology for cross posting, but I hope someone somewhere might have some
light to shed on an unexpected behavior of the latest trplayer release,
1.2.0.

I have a .rm file which no longer plays correctly after upgrading to 1.2.0
from a recent beta release, nothing else was changed. Both the beta that
worked correctly and the 1.2.0 version which does not were running with
RealPlayer 8.

The file in question is 439 kb in size. Trplayer reports that it has a bit
rate of 64.7 KB and a playing time of 53 seconds. Trplayer runs for the
full 53 seconds and terminates normally, but only produces sound for about
20 or 25 seconds, silence after that. As I say, the older beta copy worked
fine, it is only the 1.2.0 release that shows this problem.

I know a lot of speakup users also use trplayer and I am hoping somebody
might have a suggestion about what is going on here.

On a related matter: What is 'bit rate' in trplayer anyway? Sometimes it
seems to be sampling rate, but sometimes it seems to be bandwidth, and
other times goodness only knows what it is reporting. Perhaps RealAudio is
a variable bit rate system? I am really puzzled. I have found that
trplayer/realplay does a great job on mp3 files, much better than other
tools on very low bandwidth, and on mp3 biles the 'bity rate' reported by
trplayer is consistently the bandwidth and not the sampling rate; i.e.,
file size divided by playing time equals bit rate, taking units into
account correctly. Sometimes that works for .rm files but often it does
not.

I am puzzled.

Chuck


My web site is http://www.mhonline.net/~chuckh 
The Moon is Waxing Crescent (25% of Full)



^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: unexpected trplayer behavior
   unexpected trplayer behavior Charles Hallenbeck
@  ` Geoff Shang
     ` Charles Hallenbeck
  0 siblings, 1 reply; 3+ messages in thread
From: Geoff Shang @  UTC (permalink / raw)
  To: speakup

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.




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: unexpected trplayer behavior
   ` Geoff Shang
@    ` Charles Hallenbeck
  0 siblings, 0 replies; 3+ messages in thread
From: Charles Hallenbeck @  UTC (permalink / raw)
  To: speakup

Hi Geoff -


Matt has eliminated trplayer as a possible cause - he has found that my
file malfunctions in the same way when run on RealPlayer 8 without the
trplayer interface. I have asked for Peter Godman's help, so we shall
see. 
As for the bit rate deal, I have a few files which were recorded at 8000
sampling rate, and compressed to a bandwidth of 3kb, where trplayer
reports "bit rate 8k" - but other .rm files which seem to correctly report
bandwidth as the bit rate. 

Chuck
 On Thu, 1 Mar 2001, Geoff Shang wrote:

> 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.
> 
> 
> 
> _______________________________________________
> Speakup mailing list
> Speakup@braille.uwo.ca
> http://speech.braille.uwo.ca/mailman/listinfo/speakup
> 

My web site is http://www.mhonline.net/~chuckh 
The Moon is Waxing Crescent (34% of Full)



^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~ UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
 unexpected trplayer behavior Charles Hallenbeck
 ` Geoff Shang
   ` Charles Hallenbeck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).