Comment 47 for bug 195483

The trouble with the misleading reporting by apps theory is that the apps
report expected values correctly when tracks are ripped using Ruby Ripper or
Grip. Seems to point the finger at g-streamer?

On Mon, Jul 12, 2010 at 3:30 AM, Bruce R <email address hidden> wrote:

> Fascinating !
> Re-reading the thread I see that folk are using different analysis tools or
> players to decide what the results are, rather than simply listening to the
> results with their chosen player.
> Such players and tools produce different, sometimes highly misleading
> reports, such as just blandly reporting an encoded stream to be CBR 128Kbps,
> when it's actually a VBR stream.
> Even VLC Player's Ctrl_I report is misleading !
> Back when I originally researched gst-inspect lame to come up with my
> recommended profile for Sound-Juicer, I was advised to use WinXP-hosted
> EncSpot, then at version 2.0 Basic, to analyse the results, for comparison
> with WinXP-hosted CDEX encoding results.
> That resulting Histogram is as attached in my Comment to Gotit, above.
> Re-running that analysis, there's been a subtle change in results, now
> reporting VBR average BitRate of only 165 rather than 171, but the revised
> results are still acceptable when simply dwelling on a track in Nautilus, or
> better yet when playing in Exaile, whose simple interface I prefer to the
> complexity of Rhythmbox or Amarok.
> However, most players and tools are still providing misleading technical
> reports on my rigs.
> So could it all be down to misleading analysis of results, rather than
> gstreamer problems ?
>
> --
> Sound Juicer - MP3 quality doesn't change
> https://bugs.launchpad.net/bugs/195483
> You received this bug notification because you are a direct subscriber
> of the bug.
>