How to Play and Tag FLAC Files in Windows 7 using Windows Media Player (WMP)

Posted on November 18th, 2009 in Audio,Hardware & Software by andrija

If you are serious about music, you are probably storing it in a lossless format. Most popular choices are FLAC, Apple lossless (M4A) and Windows Media Lossless (WMA); there is also Monkey’s Audio which isn’t as popular. All of these choices have advantages and drawbacks. Both WMA and M4A are proprietary and the only tool that can create them is WMP and iTunes respectively. It is possible to get all of them to play on a non-windows machine, but it’s often quite difficult to do so. Even more difficult is getting them to play or stream to standalone hardware devices which is what you’d want to do at home. And support for portable devices is divisive to the max.If you choose FLAC as the best middle ground, you may want to at least be able to play it using operating system’s audio player. Windows Media Player is not a bad player but it does not support FLAC out of the box. Playing it is one thing, it needs to be able to display its tag as well as edit it. Here I will only mention how to get it to work.Download oggcodecs for your OS flavour – 32 or 64 bit. These are DirectShow filters that let WMP recognize FLAC and some other formats. Also download FLAC support, as this is what will actually allow you to play FLAC files. Finally, download the WMP Tag Plus. This one allows WMP to see tags embedded in FLAC files as well as edit them, and is the best of its breed as it integrates closely with the WMP.Now you’ll be able to deal with FLAC files as if they were any other support format (e.g. MP3 or AAC). One thing still does not work though – you won’t be able to stream FLAC to another Windows PC’s WMP or to a media extender. I haven’t had luck finding a solution for this yet.

UPDATE: as Ben mentioned below, if you use 64-bit OS, you need to make sure FLAC filters from Xiph get installed into a proper folder for 64-bit which is <system drive>\Program Files\Xiph.org because it will otherwise overwrite (or be overwritten by) the 32-bit version.

Video Encoding on a Quad Core – mp4, h264, meGUI, Linux, ffmpeg – Part 2

Posted on August 19th, 2007 in Audio,Software Development by andrija

If you want to encode video on Linux, you’re in for a world of pain. Let’s compare encoding a video file to crossing a river. Expect to have to generally learn how to build a bridge to cross to the other side – and then build it. As opposed to – at the very worst – following the instructions on how to build a bridge if using Windows, or more likely just walk right across it, as someone else probably built it and left it there already. In Linux, someone probably built the bridge before you too, but they either built it right for their specifications or they teared it down so for anyone coming afterwards it’s as it was never built in the first place.

In other words, expect to have to compile stuff yourself, apply patches and spend many hours if not days experimenting rather than being productive.

The attraction is that you hopefully can use 64-bit operating system and applications and utilize the full power of the processor, including multithreading. In practice though, things are not what they seem.

There is only one program that will actually encode a video to H.264: it’s called X264. That’s not a problem – it’s the best of its kind, comparing favourably to commercial software, and is what Windows programs use too. The problem is that if you have a multicore cpu, it will likely not utilize it nowhere near its full potential. For dual core machines differences are not drastic and is probably the reason why it slipped under the radar, but for a quad core it is very important to apply this patch. Read here why – if you have patience. I am uncertain whether this problem affects Windows – but the author mentioned that his problems occur in Linux only, so it could be an issue with how the X.264 author coded threading for Linux. Windows users score another one.

That’s not all though. There are more patches that affect the video quality. In the video I encoded there were noticeable blocking artifacts in the dark background, making the scene look ugly and last generation (macroblocks were endemic on mpeg1 and mpeg2, especially if the bitrate was low). Unfortunately there is no easy solution other than increasing the bitrate too high for my taste (say to 3000kb/s for this particular sequence – I’d prefer 2000kb/s or even less). There is however a fairly well accepted solution – adaptive quantization which can be added with this AQ quality patch. This patch adds adaptive quntization options to the command: –aq-strength and –aq-sensitivity . Alas, not even this one is without problems and needs a patching of its own. However, while this patch works if you’re using X.264 directly, it is useless if the front end doesn’t support it, that being ffmpeg or mencode. Unfortunately that makes this patch only a step above useless, unless you’re willing to complicate your life yet even more. Here’s how you would go about doing that.  I will provide an example as well, later on.
However, all of these are (probably) already compiled into Windows programs, thanks to their agile development teams and large communities. This is the trouble with Linux. With Windows someone else is going to do it for you. With Linux, it’s all up to you. It used to be the case that the tradeoff was worth it – you would gain a lot of flexibility and power by moving to Linux and learning how to do things yourself. This is not the case any more – if you use meGUI or some other tool, you’ll have no less flexibility yet much more convenience – and perhaps even speed and quality.

It is rare to use X.264 directly. That’s because it’s an encoder, not a mixer and not a general purpose tool. It expects its data to be in raw YUV format and it will output it unwrapped (as in, not in a container). It does not deal with any kind of audio (obviously), nor it knows anything about mp4 container which is where you want the output to end up packaged into. Therefore you will be using either ffmpeg or mencoder. Those aren’t front ends but kind of a swiss knife tools that can (de)multiplex video and audio from and to various containers, use filters to resize and pre- or postprocess, deinterlace, pulldown or pullup and so on.

Unfortunately neither of these tools is the “one size fits all”. That isn’t a problem either as diversity is good. The real problem is: each of those damn tools uses its own syntax to define parameters that will be used with X.264! Yes, you read it right: even though all they do is pass those parameters to underlying X.264, each of them has its own way of defining it. Not only that, but for many parameters it is not obvious which parameter in one tool corresponds to the one in other tool! Tell me that there is a good reason that an option called “bime” in mencoder needs to be called “bidir_refine 1” in ffmpeg! Especially since neither project is using its own implementation of the standard – they both will translate and pass the same thing to X.264. Unbelievable! It’s a stunning display of worst that open source can deviate into – an anarchy, a number of groups that each goes its separate way, oblivious – or worse – to others doing the same thing. Whatever the reason, the end result is even more suffering on top of pain already inflicted with this complicated subject matter.

Anyway, the fact that you had to compile x.264 unfortunately means that you’ll have to recompile mencoder and ffmpeg too. No thanks to seemingly hard linked dependencies. It’s not enough to just disable the system-supplied X.264 and install your own; the tools that depend on it will stubbornly want the other version. Whatever happened to dynamic libraries? Oh, who knows, in the end you’ll have to compile stuff yourself anyway and it’s probably for the best since it’s likely whoever compiled the os-supplied versions disabled a bunch of features that you’ll need.

More to come, but I post this anyway to make sure I don’t forget or lose these commands.

Here is a command for two pass encoding which creates a PSP playable file. You can use it if you have say an anime fansub in an avi file. Adjust the frame rate if necessary. It will produce a big file, possible a little bigger than the one you started with! The quality will be excellent but it will be overkill – H.264 is more efficient than even XviD so it makes no sense to use higher bitrate than you began with, especially since you’re probably resizing the picture down!

ffmpeg -i $1 -y -r 23.98 -s 480×272 -vcodec libx264 -acodec libfaac -f mp4 -b 1000k -maxrate 4000k -coder ac -flags loop -flags2 +wpred+mixed_refs+brdo -level 21 -subq 6 -refs 2 -bf 3 -bidir_refine 1 -ac 2 -ab 160k -trellis 1 -threads 0 -pass 1 -partitions +partp8x8+partb8x8+parti4x4+partp4x4-parti8x8 $1.mp4

ffmpeg -i $1 -y -r 23.98 -s 480×272 -vcodec libx264 -acodec libfaac -f mp4 -b 1000k -maxrate 4000k -coder ac -flags loop -flags2 +wpred+mixed_refs+brdo -level 21 -subq 6 -refs 2 -bf 3 -bidir_refine 1 -ac 2 -ab 160k -trellis 1 -threads 0 -pass 2 -partitions +partp8x8+partb8x8+parti4x4+partp4x4-parti8x8 $1.mp4

And here is the command that can do that in one pass and will produce much smaller file. Change crf to higher value to compress more, or lower value to compress less. Value of 20 is typical.

ffmpeg -i “$1” -y -r 23.98 -s 480×272 -vcodec libx264 -acodec libfaac -f mp4 -maxrate 4000k -coder ac -flags loop -flags2 +wpred+mixed_refs+brdo -level 21 -subq 6 -refs 2 -bf 3 -bidir_refine 1 -ac 2 -ab 128k -trellis 1 -threads 0 -crf 22 -partitions +partp8x8+partb8x8+parti4x4+partp4x4-parti8x8 -t “$1” “$1”.mp4

There a few things to remember regarding PSP encoding: you can use up to 3 B frames, up to 2 reference frames and you cannot use B Pyramid. You must not use adaptive spatial transform 8×8 matrix (a High profile feature) nor I 8×8 partition. You also need to specify frame rate (in the example above it’s 23.98) because your video will not play if it’s longer than few minutes. You also need to take care to set the level appropriately (I believe you can use level 3.0 if you want to use higher 720×480 resolution though I can’t see a good reason to do so, other than perhaps ability to use the same file on PS3). And be sure to use one of newer firmwares (3.30 or higher) as some features weren’t supported in earlier versions.

On the other hand, to encode a ripped DVD file with two-pass for PS3 use the command below. This page provides details about the video acquisition (ripping, deinterlacing etc). In the case below, I had an anamorphic 1:2.35 movie shot in 24fps and provided at circa 60Hz with 3:2 pulldown. This is probably going to be most common case if you watch a lot of mainstream movies. If you do have special needs and say need to deal with deinterlacing, read here. Anyhow, adjust the crop parameters as per this guide and adjust map parameters to use the audio stream that you want (e.g. english 5.1 DTS). Use mplayer to find out what is what.
ffmpeg -map 0:0 -map 0:1 -i input.mpg -y -croptop 62 -cropbottom 66 -cropleft 0 -cropright 0 -padtop 62 -padbottom 66 -vcodec libx264 -acodec libfaac -title “Random DVD” -f mp4 -coder ac -b 2000k -bufsize 10000k -maxrate 25000k -g 300 -level 41 -ac 2 -ab 172k -flags2 dct8x8+bpyramid+brdo+wpred+mixed_refs -refs 5 -bf 3 -me umh -subq 6 -trellis 0 -directpred auto -flags +loop -deblockalpha -2 -deblockbeta -1 -partitions +partp8x8+partb8x8+parti4x4+parti8x8 -threads auto -pass 1 output.mp4

ffmpeg -i input.mpg -y -map 0:0 -map 0:1 -y -croptop 62 -cropbottom 66 -cropleft 0 -cropright 0 -padtop 62 -padbottom 66 -vcodec libx264 -acodec libfaac -title “Random DVD” -f mp4 -coder ac -b 2000k -bufsize 10000k -maxrate 25000k -g 300 -level 41 -ac 2 -ab 172k -flags2 dct8x8+bpyramid+brdo+wpred+mixed_refs -refs 5 -bf 3 -me umh -subq 6 -trellis 0 -directpred auto -flags +loop -deblockalpha -2 -deblockbeta -1 -partitions +partp8x8+partb8x8+parti4x4+parti8x8 -threads auto -pass 2 output.mp4

The example below might not be as good as it can be – you could end up with some macroblocking in dark areas. As mentioned before, you might want to use adaptive quantization to deal with that, unfortunately that means using X264 directly.  The script below will do that.

rm tmp.fifo.y4m
mkfifo tmp.fifo.y4m
ffmpeg -y -i input.mpg -croptop 62 -cropbottom 66 -cropleft 0 -cropright 0 -map 0:0 -f yuv4mpegpipe -t 50 -an tmp.fifo.y4m & x264 -o output.mp4 –fps 59.94 –threads auto –progress –ref 5 –bframes 3 –b-pyramid –level 4.1 –sar 1:1 –b-rdo –mixed-refs –8x8dct –partitions all –direct auto –weightb –trellis 0 –aq-strength 0.8 –aq-sensitivity 17 –crf 20 tmp.fifo.y4m 720×352

The script will only deal with video – you will need to extract audio track separately (using mencode or ffmpeg) and then multiplex them together using mp4box.  Painful, to say the least.

Things to remember about PS3: make sure to set the level to 4.1 or 4.2. A lot of tweaking can be done above, I’ll get on that later.

Video Encoding on a Quad Core – mp4, h264, meGUI, Linux, ffmpeg – Part 1

Posted on August 18th, 2007 in Audio,Software Development by andrija

On July 22, 2007 Intel executed massive price cuts on their entire processor line. I decided that enough is enough and finally bought myself one of those new processors. The best value for connoisseur right now is quad core chip – the Q6600. I even managed to get the new-as-of-July-16th G0 revision, but that’s a story for another day. The story for this post is about what can be done with such a power. Of course, I buy new hardware just because but there is one reason which does make sense – and that is video encoding.

Now comes the punchline – I am not a big fan of movies. That might be a shocking revelation to some of my friends. After all, my shelves are overflowing with 300 odd DVDs of all sorts and genres. Let’s not dwell upon this though as it’s yet another story for another time (why don’t I post these in my blog? Another story). The real question here is why would one want to encode video at all? If one owns original DVDs, one has no need for Divx, mpeg4 or whatnot, right? So why compress your content if you’re don’t have to?

Because you might want to watch your content on the go. Say, on an iPod or PSP or some lesser know (though probably more powerful) portable video device. Personally, I only need that when I’m traveling which is luckily only once or twice a year at most.

The other reason to do some video encoding is if you need to deal with a device that can’t play the content in its original format, such as PS3. This case may occur on a more regular basis and it might also require real-time (on demand) transcoding. It depends on what you’re trying to do. You might want to keep all of your content in one place, such as PS3’s hard drive. If your content is diverse or numerous, that may not be practical. In that case you might want to be able to stream your content from whatever storage server you have to your PS3.
As a media hub, a general purpose PC can’t be beaten. It can play just about anything and it can always be upgraded with software or hardware to do stuff it couldn’t do previously. There’s nothing more flexible than a general purpose computer. But a computer may not be the best ergonomic choice – a standalone player with its customized remote is almost always easier to use and faster to operate. Unfortunately, exactly because it’s customized, the standalone player is not going to be able to handle everything. That’s why it’d be good to have a PC that can transcode in real time, on demand into any format you need. A quad core surely can do it, can’t it?

Now you’re talking: this is the real reason for all this experimentation. I don’t really care whether PS3 can play an odd anime fansub Divx file I may have – whenever content I want is available to buy, I buy and since I demand the utmost quality possible I use BluRay or DVD or HD-DVD for my video fix anyway. I will just use the HTPC for the odd file and live with some inconvenience. It’s about the challenge and the “call of technology” – I want to feel the power of this processor and will invent a reason to stretch its legs, if necessary. And I want to learn how things work – that’s what drives me in life.

So with all that out of the way, let’s talk about the real thing – how to encode videos for PSP (or PS3). At their best, these things are using mpeg4. Using that container, with H.264 video codec and AAC audio codec you can achieve highest practical levels of compression at this time.
There’s the easy way and there’s the hard way. In part 1 I will talk about the easy way. The real fun stuff is in part 2, but that’s also where most of the frustration is as well. If you don’t need the aggravation, just take the easy way .

You run Windows – XP or Vista (maybe even 2000). You don’t know your codec from your container, let alone what’s DCT or a wavelet. You do know roughly what you need though – as in what file format you require. Lucky for you, you’re in majority.

Simply, download PS3 Video 9 and/or PSP Video 9. You are using official firmware for PSP, right? If don’t think it matters but I have never tried hacked firmwares and since we are now able to watch videos in full resolution, my only reason to ever try one doesn’t exist any longer. So, select convert, select current conversion and then click on “Convert Video”. Select your file, then select values for target device (PSP or PS3) and target format you want in the now-enabled combo boxes. Resolution of PSP screen is 480×272 so this is what you should select (for firmware 3.30+ of course, why would you run anything lower anyway?). Now click start… and that’s it. If you need to encode more videos at once – of course you do, this is for traveling, remember? – then simply repeat the procedure for other files which will queue them for processing. When it’s done, copy your files to PSP or PS3 – the program will even assist you with that – and you’re done.

There are some limitations. The obvious one is that I’m assuming you’re converting an existing video. That works well with downloaded content. But what if you want to encode something from a DVD? Then you’ll need to extract DVD to your hard drive first. That can be a simple process but it can also be pretty messy one in itself due to multiple video and audio streams present, various ads and extra features, various copy protection issues and so on. Luckily, this is nothing new and I’m sure there are plenty of guides on the web and plenty of software that will help you with this step. I wouldn’t be surprised if there was a single program that would let you rip a DVD to a PSP or PS3 compatible file. I haven’t had a need to do this yet but I have tried for education’s sake to create a PSP/PS3 playable video from a DVD. This is from memory as it was done a while ago. I will summarize it below.

You can use a freeware program called DVD Shrink to extract your DVD to a single (or multiple) .VOB files. I heard some newer DVDs don’t work with DVD Shrink – supposedly you can use DVD Fab Decrypter. None of this is new or noteworthy, I’m just reporting what you can find with some Google search. But the trick to success which could make you hitting your head against the wall for days at end is this: make sure that .VOB file you rip to has only one audio stream. Otherwise your video and your audio will end up out of sync when encoded with PSP Video 9 (and probably most other software as it’s just the visual front end). As long as you end up with one video and one audio stream, you should end up with a good, useful encoding. Just be aware, in most countries it’s fine if you’re copying a DVD you own for you to watch on the go but this is considered a criminal activity – notably US. Yep, arranging a DVD you own to a different format to watch on the plane while away from home is a crime that depending on circumstances may be a “worse” offence than going to a bank armed with a gun to withdraw someone else’s money.

The other limitation is parameters of encoding. That is, you may end up encoding stuff at much higher (or lower) bitrates and quality settings than the content warrants. This especially applies if you’re re-encoding something (say a fansubbed episode of anime). You do have a fair bit of leeway here though as you can customize provided profiles to suit your needs. Of course, that means you’ll need to learn some things about H.264 codec. I will deal with that in part 2.

There is another way which I’ll still classify as “easy”. There is a very powerful application for Windows called meGUI which is a glorious front end/scripting program running on top of several famous raw processing engines. This application is very flexible and will give you close to a full control over encoding process but in a fairly user-friendly way considering the alternatives. There is no need for me to go over its usage as help – as in detailed guides with hand-holding – is provided within it. Given the example above, it would take the ripped movie (providing instructions as to how to rip them), guide you through interactive determination of its size, aspect ratio and frame rate (e.g. in order to cut off black bars present in most DVD video because encoding them would be a waste), guide you through separately encoding audio and video – providing you with the opportunity to select one of many preset profiles that will likely suit your every need as well as be compatible with your desired device, be it PSP or an iPod. It will also let you tweak each and every encoding option if you know what you’re doing, as well as let you create (AVI)Scripts which would let you script various pre-processors, scalers, filters, deinterlacers and whatnot. So whether you needs are complicated but common – in which case you’ll have to perform many steps but you’ll have guides to lead you every step of the way – or you know what you’re doing but don’t want to waste productivity on doing everything manually – you stand a good chance of getting best or close to best results possible with the least amount of aggravation, using meGUI.

There are more limitations. Software you are using may not be using all the power of your hardware. It will not take the advantage of 64-bit instructions and it’s Windows only. If you want to do things the simple way in Linux, you should get VMWare player (which is free) and install Windows and run it as a virtual machine. You will lose some performance – and unless you buy the higher versions you won’t be able to use advantage of your multi-core processor either. You also have no control over how the programs you use were compiled – they may be quite suboptimal and not take advantage of advanced instruction sets or even multiple cores. Ironically, likely due to their popularity and huge number of users, in practice it looks like the situation is actually better than if you were to do everything yourself! For example, applications are already patched to deal with bugs or performance improvements afforded by new hardware, which is something the “official” source code may not incorporate and might not do so for a long time!. I discuss that in part 2.

In summary, between PSP (PS3) Video 9 and meGUI, most users will be able to do all they need to, whether they want a (close to) one click solution or they know what they’re doing. The best thing is, most of these programs work given normal usage patterns and if they don’t, a lot of people will complain and then someone will fix it.

Comparison of Audio Extraction Quality of Several Optical Drives

Posted on May 4th, 2007 in Audio,Hardware & Software by andrija

If you often have a need to extract audio from CDs and store it into a file on your computer, and you use Windows and know a thing or two about audio and computers, you’ve probably heard of Exact Audio Copy (EAC for short). If that’s the case, you are probably interested in which optical drive will provide you with best quality and highest extraction speed – whether you use EAC or not. I will mention my own experience here and while I used EAC, a lot of the information is not specific to that program.

Let’s be realistic – most people don’t care about audio extraction quality. That is not to say they won’t care about pops and glitches they might hear once they start using those files on their iPods – or wherever else they’re listening to them. However, if grossly audible artifacts are rare, people will tolerate them. And fortunately this is what happens most of the time – if you’re using clean, pressed CD as your source with any reasonable optical drive to do the extraction.

However, the life is often not that simple. I envy people who really can live like that. You know, people who find CD holders or furniture with built-in racks adequate for their purpose. People who can fit their DVD or VHS collection in the storage space under their TVs. People who can buy furniture and find that all the designed openings and holes fit their equipment nicely. People who have total of twenty or so clean trouble-free CDs that “just work” in their players. Who are these people??

If the above is not you – or if care about sound quality, getting their money’s worth or at least care about getting things done right, then read on. After all, if you paid good money to own a CD, why would you settle for error-ridden digital copy – whether audible or not? Or why not educate yourself a little and do the job the right way – as long as there isn’t much extra hassle? Or perhaps you don’t really care but you ended up with badly glitched files due to other circumstances – CD collection in non-pristine condition or bad quality drives – and are now looking for a solution?

If you’re an average user, you probably use something like iTunes to import your music from CDs into the library on your PC (or Mac). If you have more than handful of CDs, you probably noticed that if extraction conditions are less than ideal, you can end up with audible glitches in your files. Checking the “error correction” option in iTunes can help. But that isn’t the end of the story.

iTunes and many other programs (probably) use so-called “burst” mode to perform DAE (Digital Audio Extraction). On a modern DVD or CD drive (writable or not) this is a very fast process, often reaching 40 or even 48 times the speed of playback (so a 74 minute CD would end up being extracted in 74/40 – less than 2 minutes). If the CD is clean, this will be achieved and the result will be a clean file. However, even slightly dirty CDs may end up causing trouble at such high speeds. This is where the fun starts.

Every CD (or DVD) drive has the error correction mechanism (hardware + software) to deal with these errors. It is capable of fixing them on its own, before passing them to the operating system. But it’s also possible to have the drive flag the data instead and pass it as-is to the OS, leaving the interpretation (error detection and correction) to the user software. As far as I know, not a lot of software operates in this mode – probably for obvious reasons (extra development to do the same thing that the optical drive is already capable of doing). EAC calls this mode “secure”. As you may imagine, by not having the drive correct the data, you are faced with prospect of reading raw data at least twice and comparing it, and then reading even more times when a mismatch occurs in order to determine the real data by the majority rule.

Things aren’t so cut and dry, unfortunately. There are more variables here. First, the process of getting raw data is not equally reliable on all drives. Certain features such as audio caching can make it difficult for the reading software to know what is it that it’s getting. For example, if you ask to read the same section of the drive several times consecutively, the drive might just cache the results the first time and keep returning that same data over and over. Or, it could return data with different offset each time (because it’s designed to stream audio, not provide random access), making it difficult to know the exact position of the data you’re getting within the track. And then there’s error reporting.

Optical drives are capable of reporting errors they encounter during reading. Unfortunately, this isn’t simple either. There are various types of errors, for example C1 and C2 for CDs and PIO, POE for DVDs – and these themselves may be composite errors (i.e. a combination of several other types of lower-level errors such as E11). Then there’s the issue of what is drive actually doing – is it fixing the errors it finds and reports the errors, or only reports errors when it can’t fix them? How often a false alarm occurs, and how often a real error is missed? And what is the accuracy of its error reporting?

You can try to wrap your head around all this – and this is only the beginning. But if you do, you’ll find out that there are just no simple answers. For example, a drive might report 100% of errors it finds with 100% accuracy – but due to bad mechanical design (optics) it would be reporting far more errors than another drive. In other words, it will correctly report that it can’t read a position on the disc, but that same position would be read just fine on any other drive. Or a drive might have bad error reporting accuracy and not report many cases where it actually encounters an error (or report errors when there’s none) – but the errors themselves in the extracted data are actually much less frequent than in other drives. This makes it impossible to answer a seemingly simple question “what is the best drive?” or “what drive should I get?”. While in theory there might exist a perfect drive, in reality there is no drive that is perfect (or even) sufficiently good in all relevant categories.

So I believe the only way to get useful answers in this case is to change the question. The correct question is “what is it that you want to do?”

I will start from the end – the conclusion – because explaining in detail the whole investigation I went through would take too much time and wouldn’t be interesting to many.

In my case, I want to extract my CDs into audio files with NO errors whatsoever. Provided my discs are in reasonably good condition, I feel this is a reasonable request. I would also expect very good ripping speeds on such discs. Even if discs are damaged , I expect them to be extracted perfectly – within reasonable limits of course. I am also willing to pay the penalty – speed penalty and convenience penalty – to get bad discs extracted well. I am however only willing to pay minimum convenience and speed penalty to extract good CDs – which are vast majority of my collection. Given the number of CDs I own and their condition, it would be a colossal waste of my time to take half an hour ripping just one out of hundreds of CDs, almost all of which are clean and unscratched.

This request can be rephrased: what do I use to (and how do I) rip CDs fast and with minimum amount of errors, but be reliably informed if the errors do occur? And the subsequent question is “what do I do when I do get informed about errors?”

The part “rip fast with minimum errors” depends on the quality of optical drive – it’s combination of its mechanism, optics and firmware. I first tried to determined this by making a custom test CD according EAC DAE Quality web page. It’s a cheap way to do one of those fancy CD read quality tests that big review sites put up. The results are presented below. On the horizontal axis you have time in minutes (total of 74 minutes) and on the vertical axis you have error loudness in dB with 5dB granularity; black line on top is 0dB, and so if red line is a flatline on the bottom, that means that there were no errors.

Benq 1655 DAE QualityBenq 1655 (score 81.8 out of 100)

LG4163B DAE QualityLG 4163B (score 76.9 out of 100)

Lite-On LH-20A1S DAE QualityLite-On LH-20A1S (score 87.8 out of 100)

Plextor UltraPlex 40X SCSI CDROM DAE QualityPlextor UltraPlex 40X SCSI CDROM (score 52 out of 100)

Pioneer 111D DAE QualityPioneer 111D (score 82.6 out of 100)

Lite-On LTN-527 CDROM DAE Quality Lite-On LTN-57s CDROM (score 61.3 out of 100)

As you can see, the best performance seems to come from the latest drive I got only a few days ago – Liteon LH-20A1S. Benq 1655 and Pioneer 111D are close behind. However, if I run the second test to get the C2 error reporting accuracy, I get pretty low 73.5% result on Liteon. Two other good drives are not able to report C2 in the way that the test software expects so I don’t know what their accuracy is.However, how useful is this test really? We can find it on a real example, a pressed audio CD that has errors. While this CD looks really clean, I found out by chance that some of its tracks don’t seem to extract well. Problematic tracks were 2, 3 and 10. I decided to use 10 as the reference and read it in all drives I have, and then attempt to clean the disc and get the hopefully reference (clean) data and compare with what each drive returned.

The results were surprising. Out of all drives, not a single one was able to extract track 10 without errors when in burst mode, even if the read speed was lowered (I haven’t tried very low speeds though). While that wasn’t too unexpected, I didn’t expect to get a lot of audible errors on certain drives seeing how they managed to keep the glitches pretty low during tests with the artificial test CD. And errors were very audible and quite frequent, though not in the same part of the file for all drives. Ignoring (or not) the C2 error reporting made a difference, but not necessarily in the right direction. Also, while EAC did report suspicious positions, often there were no audible errors there – and there were audible errors in the parts that were not flagged. Of course, in a number of cases it correctly flagged a problematic region. On the plus side, the extraction was pretty fast even though all drives slowed down as they started hitting errors.

When the test was run in secure mode, only Benq 1655 and Liteon LH-20A1S have read track 10 without errors. By that I mean that the binary comparison of the extracted file revealed no differences whatsoever when compared to reference file. That’s the good news. The bad news is that secure mode extraction is extremely slow, rarely faster than 8X – while there are no errors – and as slow as 1.6X overall, given that there were errors.

Additional tests showed that while Benq and Liteon were also able to read track 3 correctly in secure mode, only Benq was able to also read track 2 without errors; Liteon did have an error on track 2 even in secure mode.

So my conclusion was that out of all drives I own, only Benq 1655 was able to reliably read the (invisibly?) damaged CD. Liteon LH-20A1S was almost as good, and Pioneer 111D was acceptable (the errors weren’t frequent, and they weren’t audible). All other drives were quite simply bad – and yes that includes legendary Plextor Ultraplex 40X. Sure, many of these drives were old but so what – they are simply not capable of doing a good job today and that’s all that matters.

Unfortunately, results of this test didn’t help me much at all. In secure mode, all three “acceptable” drives were very slow, with extraction speed in single digits and sometimes barely better than real time. This is not a solution for extracting a big library of CDs which don’t have errors; it’s simply too slow. To make matters worse, the only error-free drive is not in production any longer; in fact its manufacturer was bought out last year and is now defunct. At the sample I have pretty much sucks for anything other than – apparently – ripping CDs.

In the end, I stumbled upon a solution to my problem. EAC has a copy & test feature; this will rip audio, then rip it again and compare CRC (checksum) to find out if extractions are identical. If I now extract a CD in burst mode, by taking a quick look at two columns on EAC screen (or the extraction log presented after each extraction) I will be able to find out whether there were errors during extraction. I can then put those CDs aside and afterwards extract them slowly in secure mode.

And what optical drive to use then? I cannot in good conscience recommend Benq 1655; while it seems to do a great job as CD reader, it is the worst DVD writer I’ve ever owned. This is in stark contrast with community opinion, which claims that Benq 1655 is one of the best DVD writers ever. The only way that could happen is if my unit is defective. Regardless, that points to quality control issues. But that in itself is irrelevant because Benq division that was making optical drives doesn’t exist any longer. With that in mind, I’d have to say to get either Liteon LH-20A1S or Pioneer 111 (or perhaps 112, the newest iteration which should be fairly similar). Both of them have some advantages, but I believe Pioneer is generally considered one of the best writers on market right now.

iPod Hiss, Alternative Firmware Issues

Posted on August 23rd, 2006 in Audio,Electronics by andrija

Today I was randomly reading Head-Fi, which I do extremely rarely (a few times a year at most) and I ran into some interesting new information. Well, it probably isn’t as much new to others as it’s to me, but this is my webblog after all, so news it is. Anyhow, it seems that a lot of people use or are advocating the use of RockBox firmware for iPods. What I find interesting is not that, but one of the alleged reasons for using RockBox – namely, hiss that can be heard when using iPod original firmware. The other reason – allegedly better sound quality – is another puzzle that is worth exploring.

I had iPod with me when I read it – it’s a 40G 4th generation one. I paused it, set the volume on maximum, listened carefully and then pressed my Sennheiser HD25-1 headphones against my ears… and then I heard it. Indeed it’s there. And it depends on the volume setting – if you lower it, it’s gone.

Let’s put it into perspective though. The hiss is very faint. Perhaps on very low impedance headphones it gets more evident, but it’s unlikely to be of any consequence in just about any listening situation. Furthermore, the question is whether it even matters when actually playing music. The fact that it’s only there when volume is at or near maximum points towards issues in digital domain. So the analog amplifier has low enough noise; perhaps iPod is playing digital zero signal (rather than real mute or DAC off) when paused, in which case one can hear the noise floor of 16-bit signal. I would say this is the most likely possibility. And if that’s true, it’s completely irrelevant to music listening – as long as you do get the full dynamic range that those 16 bits can provide.

So I did a RMAA measurement of my iPod (that’s headphone out, line out measurements are here). The results I got are very decent, though it looks like the noise is a bit higher than it should be and therefore it is not using the entire dynamic range. A 16-bit system is capable of about 98dB – for example my Flute 2 DAC measures like this in 16-bit mode (ignore measurements other than dynamic range and noise – this was before the DAC was further optimized). With iPod we got around 93dB – but I did have to increase input volume on the soundcard by 3dB (4dB for line out) to raise levels to what RMAA requires; this might mean that the noise floor and dynamic range are actually 96dB which would be perfectly in line with WM8971 DAC typical parameters (it is alleged that this one is closest to codec that my iPod is using). Another measurement on the web, of 3G iPod, is in line with my own regarding noise and dynamic range – about 93dB, though. These results are all superb for a portable device though

Note also that this measurement is done with no load on the iPod – it is only driving high impedance recording (line) input of my E-MU 1212m professional soundcard. When driving headphones, an ideal amplifier will still measure the same no matter the load; iPod and most other amplifiers will however change for the worse, and that change will be drastic. It’s not really their fault – there’s only so much you can do with low voltage, especially when you are also not allowed to use a lot of current. Some people – audiophiles, notably – would certainly consider sacrificing significant amount of battery life if it meant significant improvement in audio quality.

I do, however, also have an oscilloscope (or two). So I turned it on and measured the iPod, or rather just watched how the signal looks like on its output when it’s paused and at max volume. I got about 15mV peak to peak of what looked like broadband noise. At some point I thought I could isolate a 1MHz signal somewhere in there, but I could not reproduce it, so I will assume it’s mostly a broadband noise. If I capture a real-time “spectrum analyzer” (RMAA running in calibration mode, 24-bit!) screenshot, I get this. When iPod is turned off, I get this. There’s about 20dB difference between those two graphs across the board. If I play with the volume, with iPod still paused, I can easily see that the amount of this noise changes in sync with it. If you reduce volume to zero, you get below oscilloscope’s noise floor except for some high frequency spikes that seem to be around 150kHz.

I then turned on my IRiver iHP-120 which is incidentally running RockBox firmware. This player also produces hiss when paused – but the hiss is much less noticeable and does not seem dependant on the volume setting (however, when iPod’s volume is reduced, its hiss is lower than iRiver’s or even disappears). Therefore iRiver’s hiss is most likely due to analog amplifier’s noise. On oscilloscope, this player shows 10mV peak-to-peak, but there is a very strong presence of approximately 1.5MHz signal this time around, so a lot of the noise is way beyond audible range. I wonder why I was even able to hear any hiss – so I plugged headphones into my Flute 2. Even this amplifier seemed to create some hiss but at this point I was really wondering if it was audible or just my imagination; it cannot be measured by the oscilloscope’s as it is below its noise floor which is about 2mV peak to peak (at least with probes that I have which aren’t original so they pick up a bit of noise even when grounded). It could have also been the EMI from my room inducing noise in the long headphone cable – there’s plenty of EMI in this room full of cables and electronics.

In the end, I would say that iPod’s pause noise does not seem to present any kind of concern in terms of influencing the sound quality. Were it present with any volume setting, it could’ve been the reason of iPod not being able to reach limits of 16-bit sound (assuming my soundcard did not lose dynamic range for 16-bit due to having to increase its gain). However, that doesn’t seem to be the case.

I am not sure about the other claim – RockBox firmware somehow increasing audio quality. I will need to read up more about it – someone might have already found an explanation for it (I sure would hope so, this doesn’t look like very fresh news).

Technorati Tags: , , , ,