Phono Cartridge Comparison: At95e vs Ortofon Omega

I recently assembled a franken-turntable from bits and pieces I salvaged from other systems, but one of the pieces I needed to complete it is a new cartridge. I already had an At95e from Audio Technica, which is well known and well regarded among turntable aficionados as a solid budget cartridge, so I thought I would mix it up a bit and purchase another favorite from the budget realm, the Ortofon Omega. Both of these cartridges are available for around $35-40, so I figured it would be a good, fair fight. Reviews online tend to refer to the Omega as "warmer" than the At95e, which is known as a "sterile" but "accurate" performer.

Audio Technica's At95e

For testing, I took two short recordings with each cartridge from the 'tape monitor' output of my preamp, which sends a full-output signal (i.e., bypassing all of the volume and EQ from the preamp aside from applying the Redbook boost to the phono stage) directly into the audio input of my Lenovo Thinkpad laptop. I used Steely Dan's Showbiz Kids (track 1 from side B of the first disc of Steely Dan's Greatest Hits double LP) and Dr. Dre's Nothin But a G Thang (coincidentally also track 1 from side B of the first disc of The Chronic 180g vinyl remaster). I didn't do any EQ/processing/declicking, just removed the dead space at the beginning and normalized both tracks to -1 dB because the At95e put out a slightly louder signal and we typically think louder things sound subjectively better.

The Ortofon Omega

You can download my test recordings here. (Note: these recordings are short and only include the intros of the songs, and I believe them to be covered by Fair Use). I did my testing using the Lacinato ABX audio testing software, which is free to use, listening via Audio Technica ATH-M50 closed-back headphones.

If you wish to remain impartial, please do your listening/testing before reading any further.

Ok, so first off, the results are extremely close. I think anyone would be very happy with either of these cartridges for the prices they typically go for. In simple, unblinded A/B testing, I feel like I was able to hear a consistent difference between them, mostly in the vocal midrange. The At95e sounds a little roomier while the Omega sounds very tight. Whether one would consider either to be better than the other probably depends on the words I use to describe them (e.g., roomy vs loose/sloppy, tight vs constricted). I honestly don't think I prefer one over the other, it's just a slightly different character.

In proper blinded ABX testing, that all fell apart and I wasn't able to reliably tell them apart. I did about a half-dozen comparisons and my best accuracy rate was around 67%, but more often I hovered around 50% and my confidence was always quite low.

So, there you have it. Both are good budget cartridges with no major differences as far as I could tell. I noticed no difference between them in "warmth" or "accuracy," whatever that means. You should probably take reviews claiming otherwise (e.g., suggesting one or the other is better for this or that kind of music, etc.) with a grain of salt. Feel free to leave a comment with your own ABX results.

True Hq2x Shader Comparison With xBR

Background
I was shocked to learn recently that the shader I and others have long called Hq2x is/was actually a misnamed port of another shader entirely! guest.r originally put out a 2.0 scale shader with a suffix "HqFilter," which stands for a part of the color blending code. Over time, this shader was ported to a million different emulators (including the official Metal Slug PC releases) and, at some point, the name got confused with another popular emulation upscaling algorithm, Hq2x. As CPU filters have been supplanted over time with GPU shaders, no one seemed to notice that no true shader port of the classic Hqnx algorithm--in any scale--existed in any language. EDIT: looks like there was an attempt to port it back in 2005 but it never caught on because it was incomplete and had some bugs, but it's something.

Fast-forward to a few weeks ago, when a shader programmer named Armada brought this up in RetroArch's IRC channel. He shared some pics of the "Hq4x" shader in the common-shaders repo (which itself was based on the old XML shader in bsnes' gitorious repo, which in turn was based on guest.r's ePSXe shader) and an identical pic taken using a CPU-filter version of Hq4x. The differences were obvious and indisputable:

I started digging through old forum posts and it turns out that several people had noticed this over the years, but no one ever posted any comparison pics or were able to backup their suspicion in any way.

Armada and I did find that there was an old DOSBox renderer called OpenGL-Hq that was at least a step in the right direction, being a hardware-accelerated implementation of the Hqnx algorithm, and it was helpful insofar as it demonstrated how the algorithm can use an external lookup texture for the detection. However, it was not particularly applicable to modern shader language, so Armada set out to port directly from the CPU filter's C implementation.

After some intense work, which included creating a program to generate the LUTs that Hqnx bases its calculations on, Armada completed his shader port (also copied into the common-shaders repo) and it works beautifully! Incidentally, the requirement for LUTs means that a true Hqnx port wasn't even possible until fairly recently, as SSNES/RetroArch is/was the first emulator (that I know of, at least) to support LUTs in shaders.

Comparison Shots
If you've read over my previous comparison of Hyllian's xBR vs Hqnx, xBR won by a landslide in pretty much every comparison, which is no surprise because it wasn't really an apples-to-apples comparison. That in mind, here are updated pics that show a true comparison between the two algorithms (2xBR shader first, Hq2x shader right after and Hq2x CPU filter third):

The first thing you'll notice in those Super Mario World shots is that Hq2x does a great job of killing the jaggies. Much better, in fact, than ScaleHQ from the other comparison, and almost as good as xBR. There are a couple of rough edges (Yoshi's nose is a good example), but Hq2x is also *very* fast, so reasonable tradeoffs here. Hq2x does completely ignore the light texture blobs in the ground, leaving them as hard-edged rectangles, while xBR turns them into ovals. You can also see some slight lingering differences between the Hq2x CPU filter and the Hq2x shader, where the shader actually does a significantly better job of handling various detections.

On these digitized shots from Earthworm Jim 1 and 2, though, the comparison sort of falls apart. xBR is able to spot the jaggies and smooth them out while Hq2x doesn't spot any patterns at all, due to them being outside of its LUT's detection matrix. In fact, Hqnx's inability to work on antialiased images is one of the reasons Hyllian developed xBR in the first place.

It's also worth looking at how the algorithms differ in handling text. For this comparison, I included the two extremes of xBR's corner detection, with the 'a' variant as the most rounded and the 'c' variant as the most square:

 

In this comparison, Hq2x is essentially indistinguishable from xBR's 'c' variant, insofar as the text is concerned. The xBR 'a' variant is of course substantially more bubbly, which may be desirable for some games.

Conclusion

My previous comparison wasn't really a fair fight, and I apologize to Mr. Steppin for misrepresenting his algorithm. This is a much better comparison of the algorithms, and in ideal conditions, Hq2x is almost identical to xBR in smoothing while running much faster. However, in other cases--particularly digitized artwork--limitations in Hq2x's pattern detection can leave some images completely unsmoothed.

The speed of Hq2x makes it attractive for certain use-cases, such as mobile, where performance is still of the utmost importance and xBR either doesn't hit full speed at all or else drains your battery. xBR, on the other hand, can handle a greater variety of images and is more likely to produce a pleasing image with the digitized artwork that became more common in the PSX era.

A Brief Look at x265 vs x264

The next-gen open-source video codec known as x265 (h.265 / HEVC) is starting to gain some traction, since it is now included in the popular FFmpeg utility and its various derivatives, so I figured I'd do some poking around and see how it compares with the ubiquitous x264 (h.264 / AVC). NOTE: x265 is still extremely new and unoptimized, while x264 is mature and stable, so this isn't really a fair fight just yet.

For this comparison, I downscaled a 720p video to 480p with both codecs. For x264, I used a CRF value of 21, high profile, 'medium' quality preset with a 'film' tuning (these settings were chose for simplicity rather than quality). For x265, I used an RF value of 21, 'medium' quality preset with 'ssim' tuning.

During the encoding, x264 used all 8 of my AMD Bulldozer cores at approximately 95% utilization, with an average encoding speed of ~75 fps. In comparison, x265 reached only approx. 65% CPU utilization, with an average encoding speed of just 12 fps.

As expected, the videos were comparable in quality, with a slight edge going to x264 (maybe related to differences in my settings, or maybe differences in the codecs, themselves; I'm not sure and didn't delve deep enough to find out), as you can see in these sample shots (click for full size, which is still pretty small):

x264

x265

x264

x265

However, underlying that slightly better quality, x264 used roughly 47% more bits per second to encode. That is, x265 had a final bitrate of 624 kbps vs x264's 919 kbps.

So, x265 already produces a significantly more efficient encoding than x264 but the processing power required for that encoding is much greater (roughly one-sixth the framerate). Moreover, decoding is all done on the CPU right now, as no GPUs have built-in decoder chips for h.265, so that means greater power usage and shorter battery life when viewing.

x265 is already impressive in efficiency but the drawbacks of increased computational costs in both encoding and decoding and drastically slower encoding speeds make it currently unattractive to me. I'll be keeping a close eye on development, though, since it's only a matter of time before the tradeoffs are corrected (improvements in the codec), negated (implementation of hardware encoding/decoding) or rendered moot (improvements in general computation power). After all, it wasn't so long ago that x264 was considered immature, unoptimized and poorly supported in hardware vs xvid / ASP. ;)

Comparison of WebM/VP8 and x264 High Profile

So far, all of the comparisons I have found between WebM--Google's newly minted standard for video/audio encoding that will hopefully be patent-free--and h.264 have suffered from several problems:

1. Objective measurements of VP8 have focused on PSNR, which is a deeply flawed way to measure video quality and to which VP8 was specifically tuned to conform (more on this later in the post).

2. VP8 has has only been compared with inferior commercial h.264 encoders and not with x264, which is free, open-source and the best h.264 encoder in the world.

3. VP8 has only been compared with baseline h.264 and not to high profile, which has substantially better performance and quality. There is a reason for this, which I do not agree with and will cover more later in the post.

For these reasons, I have conducted my own comparisons of WebM (using ffmpeg with Google's own patches, set to preset 360p) vs. x264 baseline and high profile, with settings tweaked to achieve the highest quality. I used videos which exemplified both clean and grainy clips of both animation and live action and which are freely available from Archive.org (downloaded in mpeg2 format). For x264, resolution was reduced to the closest anamorphic value to 360p possible (368p), and I used single-pass 'target size' to closely match the size of the VP8-encoded videos. Since the WebM specification includes both VP8 video and Ogg audio, the x264 encodes also included audio encoded to the same bitrate (64 kbps using the 360p preset). Both codecs achieved adequate and comparable encoding speeds, which were faster-than-realtime (except on extremely grainy content, which slowed the high profile encoding down considerably), so I won't include those numbers here. If you disagree with these methods, feel free to conduct your own tests. Links to download the source videos are in the headings.

Comparison #1 - Clean Animation

This was actually the worst test for VP8, with visible banding on the color gradients and a disappointing loss of detail on the textures as compared with both baseline and high profile. Interestingly, baseline did a better job of avoiding jaggies on the bunny's ear than even high profile, and high profile seemed to introduce some artifacting in places, such as the butterfly... It doesn't really surprise me that x264 did so well in this test compared with VP8, since it has recently gotten some amazing improvements for animation.

Comparison #2 - Grainy Animation

High profile really earned its keep with this grainy source material by maintaining detail and avoiding introducing artifacts. Baseline kept more grain intact than VP8, but VP8 ended up with a sharper gremlin. Between VP8 and baseline, I call this one a tie.

Comparison #3 - Clean Live Action

Again, high profile really stands out in this sample with regard to the bright light. In contrast, both baseline and VP8 show some banding and blockiness, but are otherwise pretty similar. However, baseline seems to have introduced some wonkiness to the door by the upper-left corner of the '58' that's a bit troubling. Overall, both baseline and VP8 performed admirably in this test and were only slightly worse than high profile.

All three results were surprisingly similar in this test, with high profile managing to keep a bit more detail on the handwritten notes (you can barely see the notes are there at all on the VP8 and baseline encodes). I was impressed with how well VP8 does with the large text on the sign, with good, clean lines and crisp edges, though the pic itself is a little blurry overall.

Comparison #4 - Grainy Live Action

Once again, high profile demonstrates its superior handling of fine details in this sample, both with regard to the film grain and the multitude of small, moving waves. Both baseline and VP8 provide a similar loss of detail relative to high profile, but VP8 seems to have introduced some odd color distortions (a couple of faint, greenish blotches) that push it below baseline insofar as quality is concerned. However, the Penn Museum watermark looks absolutely exquisite on the VP8 encoding, even surpassing high profile. The whites are whiter, the edges sharper (though there are some visible over-sharpening artifacts around the outside).

High profile came out on top in this high motion scene, but not by as large of a margin as I had anticipated. Both VP8 and baseline only produced a small amount of banding on the gradients, though VP8 seems to have maintained slightly more detail in the motion-blurred parts as compared with baseline. As before, the Penn Museum watermark looks way better in the VP8 encode than in either x264 encode.

Conclusions

Overall, WebM isn't bad but it isn't great either when compared with x264. The popular sentiment that its visual quality is better than baseline h.264 does not seem to be true when compared with x264, though the difference usually isn't terribly large (and it manages to win a few, too). High profile h.264 obviously performs significantly better than either baseline profile or WebM in certain applications (film grain and large patches of water come to mind), while differences in other applications are scarcely discernible. Additionally, one area where VP8 beat the pants off of even high profile x264 was onscreen text, so good work on that one fellas.

Other Thoughts (tl;dr)

Leading up to this comparison, I did quite a bit of reading from other sources and I saw several arguments repeated over and over, so I want to take some time to address them:

Something that keeps getting thrown around in defense of VP8 is that it's a new codec. Unfortunately, it's not. VP8 has been in development and use by On2 (the company that developed it and was later purchased by Google) for years and, while there is apparently still much room for optimization (i.e., to make it faster and less resource-intensive), it is far from "new."

Additionally, all previous comparisons have purposely confined h.264 to baseline profile. This is because "all hardware" only supports baseline profile, so to go any higher would require new hardware and--the line of reasoning goes--if you're making new hardware decoders anyway, it would be just as easy to support VP8 as to support the high profile. This is a specious argument for two reasons: 1.) plenty of hardware already supports high profile h.264 (e.g., Western Digital's TV Live device, as well as many BluRay Disc players) and 2.) if you're going to revamp hardware, why would you go through all that trouble for the "same" comparatively shitty quality (i.e., baseline vs. VP8)? Why not go for the best quality available (i.e., high profile h.264)? The reason, of course, is freedom from licensing fees, but that's a different argument.

I've heard many people say that VP8 is *objectively better* than h.264, based on PSNR measurements. It's true that PSNR is an objective measure, but it only vaguely matches up with human perception. This fault was made painfully clear once psychovisual optimizations were added to x264: although the video output unquestionably improved, PSNR values plummeted. Why does this matter? VP8 was designed to achieve high PSNR values, which left a side-effect of preferring blurrier videos. An analogy for this is the kids who score high on the SAT because they've been taught according to its format, but they can't write a coherent essay.

I've also seen quite a few comments stating that "Google wouldn't have spent $124 million on crap." I have issues with this statement because 1.) VP8 obviously isn't crap, but that doesn't mean it's the cat's pajamas either and 2.) just because Google is chock-full of smart people doesn't mean they are infallible.

Now, the patent issue is certainly something to be concerned about, and Dark Shikari addressed his suspicions during his assessment of VP8. VP8 is very similar to h.264 in a lot of ways, according to his investigation, which could be worrisome. However, his assessment is also encouraging in some ways in that the differences between VP8 and h.264 imply that On2 was cognizant of the various patent pitfalls and was actively avoiding them. For instance, Dark Shikari noted that VP8 is missing B-frames, which is an awful shortcoming from a compression standpoint, but it's smart from an intellectual property standpoint since B-frames are apparently patented pretty tightly. Unfortunately, the patent question likely won't be settled any time soon, but I'm cautiously optimistic that VP8 will turn out okay.

Finally, as Dark Shikari mentioned in his assessment of VP8, perhaps the most serious issue facing WebM (at least in my opinion) is that the finalized VP8 spec is based on buggy C code. For reference, specifications usually describe algorithms and behaviors, then programmers create code to achieve the desired behavior. Sometimes, people who are creating a spec that is not intended to be widely read/followed (e.g., a private company creating a closed-source codec/spec [nudge, nudge]) will, rather than describing the desired behavior, copy code from their reference encoder/decoder that performs the desired function. The reason this is a problem is that, if this code contains bugs (and some of it does in the case of VP8), all decoders that want to properly follow the spec *must* include these bugs or else not conform to the spec. Dark Shikari rightly compared it to the way Internet Explorer 6's flawed execution of HTML required Web developers to write bad code that conformed to those flaws.

Now, maybe Google will create an updated spec (WebM+ or 2.0 or Electric Boogaloo or whatever) that will fix all of the bugs and stand up to x264 high profile in quality, and maybe VP8 is similar enough to VP3 that some of the striking improvements from the Theora project can be applied to VP8. Until then, WebM will be good enough for the Web, I think, and hopefully will provide a modern, free-as-in-speech codec that everyone can get behind. I'll still be using x264 for my own encoding, but it's nice to see improvements in truly free video codecs.

Have an opinion on the subject? Leave me a comment and let me hear about it.