Comment 59 for bug 195483

KennoVO - trying to respond in a less inflammatory style, your attached links made interesting reading, effectively discussing the absence of the settings used in my/other amended profiles for CD QualityMP3 before addressing the proposed use of xingmux, as then briefly revealed to the world in the Maverick Alpha2 development release.

Please note that back in 2007, rather than using a 'down among the weeds'
hex editor, I used EncSpot which rather uniquely produces histograms of
resulting MP3s. Windows-hosted, sadly it's no longer supported although
source code may still be available for its resurrection as a Linux tool.

At the time, it confirmed that Sound Juicer defaults produced 128K CBR.
Best advice was to use Windows CDEX with modified settings, effectively
in a multi-pass operation to achieve 32K-320K VBR results as again
confirmed by encSpot, but I found that by consulting gst-inspect lame, I
could achieve similar results with Sound Juicer, as further confirmed by
subjective tests.

Since then there have been several reports of use of other tools and players, including VLC Player, that falsely report 32K-320K VBR encoded streams
as 128K CBR, without folk simply listening to the difference, such is the blind
trust in such tools, reinforced by a disbelief in faulty or limited software.
This leads me to wonder what 'analysis' tools you guys have been using.

Today, although there is the rather complex Linux mp3diags, I prefer to use
the simple checkmp3 to report on encoded streams, plus actually listening
to the results.

However, with my recently restored vision I have searched for and found my
original test CD, a Deutsche Grammophon recording of the Planet Suite.
Also, although several PC failures have lost other information, I still have a
working copy of EncSpot, so I have just run tests on three differently-created
copies of the Jupiter sound track

I attach a text file of checksum results, plus four EncSpot JPEG image files.