Heh, downloaded bunch of 320kbps "green" quality fastenc encoded mp3s with WinMX. Then just for comparison downloaded some 128kbps equivalents. All of the 320kbps files were affected with fastenc stereo collapse bug.
Poor people.. trying to make high quality 320kbps files, but end up with files sounding like total crap with badly collapsed stereo...
In my opinion at least encspot should warn about this somehow, and not just show automatically green quality...

Do not trust this 320 kbps files. Many of them are just recoded 128 kbps files by some newbies who believe they can increase quality this way

JohnV,

The problem is whether different versions (and even different settings) of fastenc can be algorithmically detected or not. I did some test runs and seems that encspot cannot recognize between MMJB fast, fastencc.exe 1.01 and fastencc.exe 1.02 files.

Since fastenc doesn't add any particular header which clearly states encoder's version number and other information my work hypothesis would be this kind of exact recognition would be impossible.

What complicates matters even more is that only certain older MMJB, Nero and fastencc.exe 1.01/1.02 are affected by the stereo collapse bug. Using fastencc.exe with medium/high settings doesn't produce this phenomenon.

Quite only solution I can think of would be to mark every fastenc-encoded MP3 as yellow. Which I think wouldn't be a bad idea at all since probably 95% of fastenc'd files have collapsed stereo

Yeah, that's yet another issue. I can hear if the file is 128kbps transcoded though. Still most of these 320kbps files are crap.

It was just funny that especially all these 320kbps files were all affected with stereo collapse bug. Just imagine what kind of quality would transcoded stereo collapsed MP3 offer... And Encspot shows green quality.

I think safest and most realistic choice would to mentally consider everything from the internet as "red" quality. The absolutely "best" quality MP3 I've ever downloaded was a LAME 3.87 VBR joint stereo. Probably --r3mix'd according to bitrate and a 19.5 lowpass.

And I'm not still sure should the "Quality MP3 of the year" prize given to Blade 128kb/s simple stereo or Xing (very old) 128kb/s dual channel.

If I make a quick statistic about encoders of my ~400 downloaded MP3's, in quantity clear winner is Blade, followed by Xing (very old), followed by Xing (new) followed by FhG (producer pro). I wonder why Blade is the most common encoder I've run to, did/does some particulary well-spread cd-ripper default to Bladeenc or something? I would think FhG was the most common since it's been around for longest and it has "l33t w4r3z 4ppr0v41 s34l" on it.

Through these experiences I think a Zeroth law of internet file transfer can be led, being

[b]If there exists some encoder or a particular version of an encoder which results to inferior output compared to others that is the encoder vast majority of people will use and will continue to use until a worse encoder is discovered.

For the time being, there hasn't been a single violation to this law, neither in video nor audio. And this behaviour will continue infinitely since I'm sure these people could ruin idiot-proof ogg's and mpc's with incrediable efficiency, probably by transcoding from their Blade 128 kb/s MP3's

Edit: typos

Wouldn't everyone be using the ISO reference code then?! If it's anything like the AAC reference code someone posted on here, it's got to be the worst ever!

Most of the MP3's I download these days are Xing(new), followed by FhG Pro, then fastenc, then l3enc.

Sure, Xing(new) is bad, but at least it's not horrible

You'll perhaps be surprised, but there is an encoder which is even worse.
It's called Shine, and trust me Shine is really lame. (btw Lame really shines)

While we're talking about bad encoders :

- Where do I get that Shine thing that's so lame?
- And where do I get Gogo?

CU

Dominic

For Gogo there are some binaries at mitiok.free.fr.

For Shine I'm not sure if there are binaries for x86, but for sure there is source code.

Volcano

I can send you Gogo307 .exe and DLL if you can't get them elsewhere. Yet more stuff compiled for fun!!

john33

Or you can send them to me, and I can upload them to
my page...

Just a question - Is gogo so terrible? I thought it was
just Lame 3.88 core (In the case of Gogo 3.x), with
assembler and MMX/3DNow!/SSE optimizations.

Of course, Gogo 2.X is bad, since it is forked from
Lame 3.23...

Regards;

Roberto.

Want to hear some REALLY bad encoder?

download everything from:

http://www.psytel-research.co.yu/temp/old_iso/

And then type:

encaac 128000 filename.wav filename.aac

You will need an AAC player to listen to these, but believe me - files sound HORRIBLE. Also try the 96 Kbits/s - even worse!!!

This is ISO/IEC 14496-5 AAC Reference Software

LOL

Congratulations, Mr. Dimkovic, that's probably the worst
encoder ever!

I wonder... It probably took lots of work to get to such
bad quality!

On the other hand, the new (?) Psytel Fastenc seems
very good. And Fast! 1.18X realtime on my K6-2 500,
128Mb RAM. Faster than Andree's mppenc.

Keep up the excellent work!

Regards;

Roberto

Well, people that wrote it worked very hard to make it THAT bad

You can download the source code for this encoder from:

http://isotc.iso.ch/livelink/livelink/fetc...f_Home/ITTF.htm

(look for 14496-5)

Regarding my last post in this thread...

Ivan;

Is there any tradeoff speed/quality in Psytel Fastenc, or
just code optimizations / tweakings?

Thanks;

Roberto

There are tradeoffs, Fastenc contains psychoacoustic model and bit allocator optimized for fastest execution, not for highest quality.

However, it still maintains good quality.

It is not optimized for AMD CPUs, for example, while it runs 1.18x real-time on your AMD K6-2 500, it runs 4x real-time on my PIII 850, or 1.1x real-time on my PII 333 notebook.

I remember trying to get some quality out of the NTT VQF encoder included in the MPEG-4 source.....Now that was bad, even at 160kbps it hardly sounded great....Ive still got it if someone wanted to hear _real_ bad encoding... (I gave up very quickly on trying to make it better

-Nic

ps
Ivan what are you currently doing? Have you slowed down the work on the MPEG-4 video encoder? Just me being nosey (again

I can compile latest MPEG-4 VM source code, it contains Twin VQ encoder as well And I also remember that it was terrible, too...

No, I haven't slowed down MPEG-4 video encoder development, current version is really fast (it is based on ISO 14496-7 optimization model, with PMVFAST motion estimation) - It is included in authoring tool demo, I think it is able to do 60 FPS encoding on PIII 850 (with lower quality settings)

I am working on the MPEG-4 Authoring Tool, currently adding support for real-time encoding and broadcast (like WebCine encoder) - I have already positive results with MPEG-4 IP Radio, which is working in small LAN multicast environment, and Philips WebCine player is catching and playing broadcast very well!!!

Once I integrate audio and video capture into authoring tool, it will be ready for the official (non-developer) beta, stay tuned!

*twiddles thumbs*

Many new video codecs have popped up after DivX (original) appeared, but none have showed any real improvements over what proprietary solutions (RM, WMV) can still offer. Though VP3, DivX4 and the (very alpha) unnamed project at videocoding.de are all efforts that should be admired, people who just want to distribute high quality videos now still have to settle for non-standard implementations. If you can pull it off, that is, to have a codec that is both MPEG-4 compliant and of better quality than existing codecs, that would be quite an effort. Best of luck to you.

Well, fully optimized MPEG-4 solutions will begin to appear soon,

Philips WebCine, Envivio Encoding Station, etc...

Also, latest MPEG tests showed that new codec, called H.26L (to be integrated in one future profile of MPEG-4) is already superior to current MPEG-4.