Does pono's 24-bit audio matter? Hear for yourself. - <AUTHOR> http://blog.beatunes.com/2014/04/does-24-bit-audio-matter.html <comment><USER2> This test is flawed in a few ways. The and the error lies in the source material. The why would there be a perciveable difference between the same inferior input shown to both encoding formats. Changing between encoding formats is a topic of its own but the problem here is similar to getting a 640x480 compressed jpeg and putting it into a 1920x1080 lossless format and the same source into a 1280x720 lossless file and saying. What's the difference? They both look crappy! Many people have an opinion on high res audio formats but they are so many places to go wrong. Audio should be given a little more credit for it immersive ability. When done right it can take you places. Something to consider is that our eyes can only see 1 octave of information our ears can hear 10 octaves. Whilst these high res formats aren't needed for every application they do make a big difference when the source material can take advantage of it. I feel in 2014 music should be released in the best format available from the studio and if u want a crappier version so u can shove 5000 songs on your iWhatever that's your choice.

<comment><USER3> It's not the same as the same inferiour source material.

When you apply negative gain to the 16-bit signal, it has less amplitude in absolute terms, but it should have all the resolution of a whole 16-bit sample in that space.

The point is that whether that 16-bit signal is represented with the lower 4 bits of a 16-bit sample, or the lower 12 bits of a 24-bit sample, you can scarcely hear anything at all, let alone a qualitative difference between the signals.

192KHz is not a higher quality format, it is a production format. The purpose is to reduce the cost and finality of anti-aliasing filters when sampling the signal, it is just cheaper to manufacture. There's a good reason for this being the standard in professional audio, they need to buy a LOT of audio interfaces, many studios will have thousands of such inputs.

Thanks to the basic laws governing signals, we know with near certainty that not only is 192KHz overkill, but so is 48KHz, and so is 44.1. Without significant new evidence showing humans hearing signals with frequencies greater than 24KHz, you will not make any convincing argument as to why we should go with any sample rate higher than 48KHz for human listening.

As for 24-bit, it is another production interchange format. It's there so that you don't need to stand around adjusting gain knobs on audio interfaces so that you get decent fidelity but also don't clip. With 24-bit you can just sample your audio once, and assuming it's within a reasonable range, you can adjust the gain in the discrete signal. There is some indication that 16-bit sampling is less than completely ideal. The very best ears in humanity(newborn ears) distinguish about 21 bits in the safe ranges of amplitude, 24-bit may make sense in an audio system for newborn babies.

I feel that in 2014, music should be released in the best format available from the studio, and if you want a crappier version so that you can shove only 100 songs on your iWhatever, that's your choice.

</comment></comment><comment><USER4> This test is pretty uninteresting, but I'm glad the author linked to the Xiph article because it's one of the best articles on the subject I've read.

[http://people.xiph.org/~xiphmont/demo/neil- young.html](http://people.xiph.org/~xiphmont/demo/neil-young.html)

<comment><USER5> The author admits that "16 bits does not quite cover the entire theoretical dynamic range of the human ear in ideal conditions". But then the author concludes "let's not use 24 bits anyway because it doesn't really help anyway, and it wastes space"

Wastes space? In an age where we stream gigabyte movies? Do we need to remind the author that we're no longer in 1982 and that we have evolved beyond floppy disks?

<comment><USER6> >> Wastes space? In an age where we stream gigabyte movies? Do we need to remind the author that we're no longer in 1982 and that we have evolved beyond floppy disks?

Clever way of leaving out just how much space it takes up (takes up 6 times the space [0][1]) also as both this author and Xiph concluded you can't really hear the difference. When we stream HD (As you put it "Gigabyte movies") we are getting a clearly superior product. I can easily see the difference between 480/720/1080 whereas I seriously doubt I can hear the difference between 16 and 24bit audio. Yes space is cheaper than it used to be but it's neither free nor unlimited, not to mention the primary way people listen to music nowadays is probably on mobile devices where space is still at a premium or they enjoy their music via a streaming service a la Spotify/Rdio/Google Music where bandwidth is at a premium (And storage factors in here as well due to either being able to store less songs locally or in cache due to larger file size).

[0] [http://people.xiph.org/~xiphmont/demo/neil- young.html](http://people.xiph.org/~xiphmont/demo/neil-young.html)

[1] [http://blog.beatunes.com/2014/04/does-24-bit-audio- matter.ht...](http://blog.beatunes.com/2014/04/does-24-bit-audio-matter.html)

<comment><USER7> The six times figure is for 192kbps _and_ 24 bit. The move from 16 to 24 bit alone would just result in an increase of 50 %.

<comment><USER6> Do you have a source for this? I was under the impression that:

        filesize(192kbps + 16bit) = 6*filesize(192kbps + 24bits)

Also the point of both articles is that: You can't hear the difference.

Look at MP3 vs WAV (or FLAC), MP3 won out (for consumers) because of it's filesize being so much smaller. Look at the compression differences:

>> Uncompressed audio as stored on an audio-CD has a bit rate of 1,411.2 kbit/s,[note 2] so the bitrates 128, 160 and 192 kbit/s represent compression ratios of approximately 11:1, 9:1 and 7:1 respectively. [0]

At the best quality listed here (192kbps) MP3 is 7 times smaller than it's WAV counterpart. I just don't see people paying for 6x the space for something they can't tell the difference between. If anything history has proven this not to be the case.

[0] [https://en.wikipedia.org/wiki/MP3#Bit_rate](https://en.wikipedia.org/wiki/MP3#Bit_rate)

<comment><USER7> Trivial arithmetic:

        192 ÷ 48   = 4
         24 ÷ 16   = 1.5
          4 ×  1.5 = 6

The six times is also on the wrong side of your equation, I guess.

But if you need a source, I can cite what you cited:

> Unfortunately, there is no point to distributing music in 24-bit/192kHz > format. Its playback fidelity is slightly inferior to 16/44.1 or 16/48, and > it takes up 6 times the space.

They were talking about both sampling rate _and_ bit depth.

Oh, and just for the record, I do agree with the general idea that it's useless to ship audio to consumers as 192/24, for the same reason it's unwieldy to publish photos online as 20+ MiB raw files (even if browsers could display them). I was just noting that the size comparison included both sampling rate and bit depth and not just one of them.

</comment></comment></comment></comment></comment></comment><comment><USER8> I have pretty good headphones (Sony MDR-V6). I can hear decently enough (although getting older). Like I noticed that the Deutche Gramaphone 111 years music collection I bought (256kbps mp3s) has taped performances from the 70 & 80s which have some tape his.

Honestly as an end user its really good enough. If I was remixing this stuff and processing the audio I would want the non-compressed. (similar to shooting Raw photographs ). But at 256kbps honestly it really is amazingly good. thinking back to cassette tapes and records, its astonishing.

As for the tape hiss on the classical music, the performances are so good I just ignore it. Sometimes I think people get worked up about the quality of the recording and ignore the quality of the performance.

<comment><USER9> > Sometimes I think people get worked up about the quality of the recording > and ignore the quality of the performance.

This is the main problem with audiophiles.

Improve your equipment until it makes your music awesome, then just enjoy it.

<comment><USER10> "Normal people use their equipment to listen to music. Audiophiles use music to listen to their equipment."

</comment></comment></comment><comment><USER11> It's not only the difference (or none) between 16 or 24-bit, but it's mostly about the quality of the DAC that is being used - in this case a very high-end one.

Then again, it's been proven time and time again that the average person can't even hear the difference between mp3 or FLAC.

Considering you'd also need proper high-end monitor headphones, i believe this is more about marketing, the brand and the pitch than it is about what you actually get or can actually use.

\+ it can only hold about 2000 FLAC files even with expansion card.

<comment><USER12> without the big name attached I doubt it would have had much traction. Its merely a very good marketing exercise. Snake oil for the 21st century. No better than all the joke techies used to make about HDMI cables.

I always like Alan Parson's quote, audiophiles use your music to listen to their equipment

<comment><USER13> A 24-bit sample depth is not completely useless and silly in the way that gold plated HDMI cables are. You _can_ get a real improvement in dynamic range with 24-bit samples, allowing a song to have quiet parts and loud parts with no loss in quality in either, which is hard to do with 16-bit samples without losing quality for the quiet parts or using dynamic range compression and having everything sound roughly the same.

Of course, few people actually want impressive shifts in volume in their music, because prog is dead and no one wants their headphones to suddenly blow their eardrums out. Gotta compress the shit out of that dubstep for the kiddies! Somewhat ironically, greater bit depth in audio makes a bigger difference for film than most music because of this.

</comment></comment></comment><comment><USER14> One thing that is alluded to but perhaps not explored fully is the use of noise-shaping dither techniques which rely on pushing the noise out into the ultrasonic region. Xiph mentions it in the context of 16 bit resolution, but I believe it interacts with the discussion of 192 kHz sampling.

Significant noise power at ultrasonic frequencies (or even a skewing towards higher audible frequencies) represents a problem for tweeters & amplifiers both in terms of the intermodulation distortion mentioned in Xiph's article and in terms of power dissipation at the business end. IIRC Dell and VLC are having a falling-out because VLC's soft clipping is damaging the speakers in certain Dell laptops.

<comment><USER15> Here's the discussion on that Dell issue. [https://news.ycombinator.com/item?id=7205759](https://news.ycombinator.com/item?id=7205759) "Simply said, the sound card outputs at max 10W, and the speakers only can take 6W in, and neither their BIOS or drivers block this."

<comment><USER14> That's actually good design - the intention being that any clipping can only be due to software (which you can fix), not underpowered amplification hardware (which you can't).

<comment><USER15> It's certainly a software issue, but the fault is in the BIOS, not VLC.

</comment></comment></comment></comment><comment><USER16> It would take highly dynamic music to really hear more bits. The quiet passages is where it makes the difference. Most music is compressed beyond the need for anything other than 40db of dynamic range.

I barely can tell the difference between high sample rate 8 or 12 bit audio and 16 bit audio. In some circles I hear people talk about that "gritty" 12 bit sound, but its usually not properly dithered, heavily filtered, 20khz or less sample rate and generally destroyed on purpose.

Audio is generally the best arena for snake oil since subjectivity is so high. I cannot believe that Focal Grande Utopia EM loudspeakers(180,000 usd MSRP) exist in quantity, but I know two people who own a set in their (comparatively) modest living room. I have heard them in action, they sound great, but Im not sure that I heard anything in any of the music that I hadnt heard with good headphones or speakers. At what point is it "good enough"? I own plenty of recordings that no amount of hifi audiophilia will help.(many that I recorded myself ;) )

</comment><comment><USER17> The author is likely using a 16-bit audio card to listen to the result, which is going to clip the least significant bits off anyway. If you undo the shifting with sox -v 4096, the quantization noise in the 16-bit version is audible, even on laptop speakers.

<comment><USER18> This is my only issue with the article - it's alluded that the -v and -b flags _only_ perform multiplication and bit shifting.

By default, this is __not __true because sox will use a higher bit-count and perform dithering when converting to a lower bit format (ref[http://blog.beatunes.com/2014/04/does-24-bit-audio- matter.ht...](http://blog.beatunes.com/2014/04/does-24-bit-audio- matter.html?showComment=1397570941495#c7516054401833345657) ) in order to remove the extra bits while reducing the impact on dynamic range.

In all fairness though, this is the same argument used in the Xiph article ( [http://people.xiph.org/~xiphmont/demo/neil- young.html](http://people.xiph.org/~xiphmont/demo/neil-young.html) ) in an attempt to justify the use of 16-bit over 24-bit, the prior allowing for a comparable dynamic range with the use of appropriate dithering techniques. I just think it's important to note that the process used with sox is doing more than simple arithmetic bit-shifts/multiplication.

</comment></comment><comment><USER19> Weird that the author uses a 'ordinary MP3' as source for the test. Garbage in, garbage out. Right? Would be a better test with a very high rez audio file.

<comment><USER3> I suspect it's heavily compressed audio. His argument is that you'll have a hard time hearing it at all, so if anything's going to help you hear it in the first place, it's garbage in. garbage recordings are the only ones which will survive this test.

Anyway, nobody here is both qualified and willing at the same time to tell you what you need to know about this topic. The article referred to, written by Monty at Xiph, should give you a very good overview of how this works .

[http://people.xiph.org/~xiphmont/demo/neil- young.html](http://people.xiph.org/~xiphmont/demo/neil-young.html)

<comment><USER20> > nobody here is both qualified and willing at the same time to tell you what > you need to know about this topic.

Maybe people who work in professional (not consumer) audio? Who design these systems for a living?

<comment><USER3> Hence "and willing".

</comment></comment></comment></comment><comment><USER21> Surely the test is slightly invalidated by converting an MP3 to wav? surely you would take a master/studio recording and convert that to wav/whatever

<comment><USER14> The test is most likely invalid - unless told otherwise SoX adds dither. Try adding -D, I expect the results will be different.

</comment></comment><comment><USER2> Frequency response and dynamic range are low hanging fruit in high res audio debates. They are not the only factors in accurate reproduction of an input wave. What is rarely considered is the temporal resolution of the format. Which is the formats ability to describe change over time. To plot a graph but depth is the y axis resolution and sample rate the x axis. Again I'm talking to temporal resolution. Transient response is directly effect by this. The link below shows the advantages of hi res audio formats inside the human hearing range. So if accuracy is of concern high res formats DO hold more information about the original wave form. If file size is of concern hi res is not applicable.

[http://www.eirec.com/DPimages/digisqwvtest.jpg](http://www.eirec.com/DPimages/digisqwvtest.jpg) This is an example if transient response of different sampling rates.

<comment><USER20> I tried to find the context for that image but there wasn't anything on the site. The image is most certainly incorrect -- or more likely, looking at the output of the analog electronics after the DAC.

Sampling theory says that a perfect square wave can be represented at any frequency below Nyquist. That doesn't mean that the codec or the analog electronics are capable of responding instantly at those frequencies, but that has nothing to do with the fact that a 1kHz square wave can be perfectly sampled with a 44.1kHz sample rate. The image is simply incorrect.

Transient response in the real world is generally limited only by the acoustic transducer response of the system, because everything else has the ability to respond much faster than audio rates. With Pono, this means that the earbuds or headphones you use with the player will have a greater affect on the transient response than the electronics inside.

<comment><USER2> This image is from RME a sound card maufaturer. And the image is of the analog output after dac. So still in the electrical domain. Short comings of a playback system has what to do with the accuracy of a recoding medium? There are SO many factors that stop and audio signal reproduction from being perfect. But the signal domain is the easiest to make better. Transducers that have to fight the law of physics for accuracy are the obvious weak point. But as with anything rubish in = rubbish out. Before you even get to the weakest point of an audio system the transducer (the speaker) transistors and amplification have their own short comings the accuracy of an amplifiers transient response is measured by its slew rate. A square wave is impossible for a speaker cone to reproduce in theory the rising and falling edge is describing an instantaneous movement. A speaker cone can't do this, inertia says no. And this is called distortion. As every part of the system introduces its own distortion the accuracy gets less and less. To accept distortion at the signal level in the persuit of accuracy is counterintuive. But if your system can't take advantage of this extra accuracy, go ahead and use a lesser format, no sense in the extra file size. If you want a reference quality signal, use the high res formats. To be clear here I'm not saying I want to listen to digitally encoded square waves, a square wave is a tool for showing the accuracy of input=output. A square wave being the hardest analog waveform to capture and reproduce. I am objecting to the idea that hi res formats have no advantage over what we are used to as consumers. It is the content distributors that are taking advantage saying that 24bit/96k is more expensive. The bandwidth and storage does not make this a more premium product you should be paying for the album not the format. But why limit choice because the masses can't see the benefits. If you buy the album you as the consumer can choose the format. I'm not sure if all this arguing stands up to pick whatever format suits your needs. This argument should be if I bought the album why can I choose the format most applicable to my playback needs/desires. And if your concern is that company's charge more for the high res, that refeclts poorly of the distribution company. If you think it's a waste of space just download the lesser format. If I had a choice I'd download it as it left the studio/mastering house.

<comment><USER20> Not sure what point you're trying to make here, but I was responding to your post implying that 192kHz sampling rate improves transient response. It doesn't improve it at all. While there is sampling "distortion" by way of quantization error, this error is inaudible because we're sampling at 24 bits, beyond the dynamic range of human hearing. High sample rates actually REDUCE audio quality because they sample ultrasonics that will interact within the audible range and potentially damage speakers or pick up EMI interference.

It has been proven over and over via ABX testing that high res formats are completely indistinguishable from a 24b/44.1kHz master. And further studies have proven most audio engineers can't distinguish between lossless audio and 320kbps MP3. That's what the Xiph link elsewhere in the thread shows.

</comment></comment></comment></comment><comment><USER22> re: "It's useless because most people can't hear the difference."

Sure, but when sampling and then processing things, you can consider it "headroom". Just like it's not hard to edit a photo in a few steps that the limitations of 8 bits per pixel begin to show. Though I suspect sampling frequency is a lot more important there, 24bit can't possibly be "too much".

Yes, I understand that this is not a good argument for consumer products to be more expensive and need more storage, just so musicians of the future, or pirate musicians of today, can have a better time. So I think the best plan is to encourage everybody to become hobby musicians, then it would be an easy sell.

</comment><comment><USER23> Newborns can hear a SNR of about 120dB which is around 21-bit. So 24-bit seems useless for playing back audio.

But I always wonder how much of the sound we hear by feeling (skin, hair vibrations). Because maybe I can't hear 1Hz, but I can very well feel it.

<comment><USER24> You can definitely "experience" the sub-audio range, but you don't need 24 bits to do that.

I have very sensitive hearing, I hear things most others cannot. I can detect 192kbps vs 320kbps mp3 encoding. I cannot have any switch-mode AC/DC transformers in my bedroom because the switching noise actually keeps me awake (I charge my phone in the kitchen, most people think I'm mad when I complain about the "noise" :)

Still, I've never been able to detect frequencies above 20Khz or hear the difference between 16 and 24 bit. I think anyone claiming to is full of crap.

<comment><USER25> My laptop whines when I scroll down image-heavy pages. Thus far, I've had a grand total of one other person comment on it.

</comment></comment></comment><comment><USER26> At the last year's IFA ([http://b2b.ifa- berlin.com/en/Home.html](http://b2b.ifa-berlin.com/en/Home.html)) there was a demonstration of a 24-bit audio player with corresponding high quality audio files and headphones. The results, even though it was a single test, were _very good_. Of course the issue is, the whole chain has to be 24-bit, if you're going to pump your 128kbps MP3 there the difference is probably negligible (not to mention the 1-bit DACs commonly used, that's one of the elephants in the room)

About the MP3 files, yes, the difference is audible. But of course you need good headphones.

</comment><comment><USER2> There has been a lot of talk about quantative aspects of but little about the qualitative. What does a 18khz square wave look like wher recorded and reproduced in 44.1 kHz. How is phase affecte?. Phase of an audio signal reaching the ears helps you perceive distance and position. How many samples are used to represent the frequencies at the higher end of the audible range. What is the quantization error difference between 16 and 24. And if the author can't hear the difference between 4bit audio and 12bit audio I question what he/she is listening on. The aliasing would be HUGE.

<comment><USER14> An 18 kHz square wave sampled at 44 kHz looks like an 18 kHz sine wave, everything after the fundamental frequency is well outside the Nyquist limit and will have been thrown away by anti-aliasing filters. And furthermore you couldn't hear it even if it wasn't. Fourier decomposition of a square wave gives the sum of odd multiples of the fundamental, the next frequency is 3 x 18 kHz = 54 kHz.

<comment><USER2> Okay now actually look at the response on Matlab. As you get closer to the nyquist freq there are less samples to describe the wave. And while you get a bastadised 18k signal it's a far throw from what you put in. Anf while most are crying your splitting hairs the frequency response and dynamic range arguments pale in comparison to making the exact wave you put into the encoder come out. On the right system with the right recording the tiniest nuance in a room reverb helps trick your brain into believing the sound as actually happening. And this is not important to all listeners. But people saying that it makes no difference and is not important as a format to release music in are thinking only of their current needs and experiences. If you have actually heard a good recording on a good system in a good room you will know what I'm talking about. If listening experience has been laptop speakers, headphones and your mum and dads mini system then I totally agree any more than 320kbs mp3s are overkill. But to say that high res formats gave no place in consumer land is to show your lack of understanding of different people and different needs. In the age of iTunes you surely you buy the album and download it in whatever format u see fit. If u think audiophiles are wackos go get ya 320's. I would like to get it as I came fr the studio. The best it can be is as it came from the studio.

<comment><USER14> First off, forget about MP3; I'm not arguing for a lossy standard.

You can't get an 18 kHz square wave out of a system with 44 kHz sampling. You need at least 1 harmonic before it'll even LOOK square, and that requires a frequency response out to 54 kHz, ie. a sampling frequency of 108 kHz. You CERTAINLY won't find one in a reverb tail, even assuming you had a generator for one in the first place (you might JUST get one from a cymbal crash, but I don't think the physics works)

The point being, your source material can't contain an 18 kHz square wave either since it's been through a studio production system with the same antialiasing filters.

Since you know nothing about me but seem to be making assumptions anyway, here's some background. I've worked in broadcast audio; I own studio recordings in 24 bit / 192 kHz (Linn release of Mozart's Requiem, studio master series). I also own studio equipment that can actually play it. Audiophiles are, by and large, cash cows for companies with no scruples.

<comment><USER2> Good an audio nerd. I am making the point about the square wave close to the nyquist to point out the short comings of a format for accurately reproducing an input. Square waves in the real world are rare but I am arguing for a format that produces the most accurate representation of the intended signal. Imagine the situation where i have my guitar cab set up and I have a square wave (distortion) coming out of it and I far mic it up so as to capture the room a give a feeling of space. To really feel like your there you would want the resulting complex wave made up of the 18k direct sound from the cab and the room response a recording medium that can't do that accurately is second rate especialy when the formats are out there. And the higher the sample rate the further from the nyquist that 18k is and the more samples that can be used to describe the resulting wave an the more convinced my brain is that sound is real.

<comment><USER14> ...right up to about 20 kHz, whereafter YOU CAN'T HEAR THEM. Hence 44 kHz sampling.

Seriously, A/B test this, you might be surprised.

Also if you think that's anything like a square wave coming out of a guitar speaker (or that that is even desirable in the most case), I've got a bridge to sell you. And yes, I do play.

<comment><USER2> [http://www.eirec.com/DPimages/digisqwvtest.jpg](http://www.eirec.com/DPimages/digisqwvtest.jpg)

Okay here is a picture of what I'm trying to explain. And the author of this picture used a frequency much further inside human hearing range. This is transient response test I guess. My main argument is for the verbatim capture of the input wave. It will make the sound at 10k but it isn't the same wave that went in.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> The methodology might be flawed, but the point stands: We can't use the full dynamic range of a 24 bit signal for audio. Great converters have 20-21 bits of range and if we fully use this range, hearing damage will start at maximum volume levels. If the volume is kept the same between the two files, there is a 48dB drop in level - not inaudible, but there are very few source materials that will actually use the extra dynamic range. On top of that due to fletcher munson curves we will only hear content in the 1-4kHz range at that low volume level.

<comment><USER27> _Great converters have 20-21 bits of range and if we fully use this range, hearing damage will start at maximum volume levels_

but that doesn't have anything to do with number of bits? I mean, an audio player system is basically a digital stream sent into a DA converter outputting an analog signal which is then fed into an amplifier where the signal is amplified and then sent into speakers of some sort. No matter if you have an 8bit audio stream, or a 128bit audio stream, the stages afterwards play a much larger role in the hearing damage caused. Also not all DA converters ouput the same level to begin with. Some are -5V to 5V while others (single power supply) can be 0V to 5V, etc etc.

<comment><USER20> Hearing damage as a result of loudness; the electronics have little to do with it. If you set up a 96dB (16 bit) system such that you can hear the lowest bit toggling, your maximum volume will be 96dB above that. 96dB SPL is loud but not painful for average listening.

If you set up a 20 bit system (120dB) so that you can hear the lowest bit toggling, 120dB above that will most certainly cause hearing damage if used for very long.

144 dB (24 bit) or more SPL will cause near instantaneous damage and pain.

</comment></comment></comment><comment><AUTHOR> For the test the quality of the input does not matter. You can conduct the same test with a beautiful 24-bit recording as source, you would still not be able to hear much in the end.

And that's the point.

When you print a photo in size 9x13cm, does it matter whether you print it in 10,000dpi or 20,000dpi? Hardly, unless you always run around with a microscope.

And it does not matter, whether the photo was originally a good picture or not.

<comment><USER22> > When you print a photo in size 9x13cm, does it matter whether you print it > in 10,000dpi or 20,000dpi? Hardly, unless you always run around with a > microscope.

It can matter when you put it in a scanner though. I tried scanning some old photos, they look _horrible_ compared to even my puny 8mp camera. Then I tried scanning a piece of cloth, and was blown away by the detail..

</comment></comment><comment><USER2> More to it than frequency response and dynamic range. The goal should be for the most accurate reproduction of the input waveform. Here is a pic of transient response for different sample rates. [http://www.eirec.com/DPimages/digisqwvtest.jpg](http://www.eirec.com/DPimages/digisqwvtest.jpg)

</comment><comment><USER10> So I converted a few tracks to 8-bit with noise shaped dither. Have a listen and remember that the noise floor is now 48dB higher (8-bits) than it would be with 16-bit.

[https://www.dropbox.com/sh/1h4z0quoybo60c0/O1SwT35Nve](https://www.dropbox.com/sh/1h4z0quoybo60c0/O1SwT35Nve)

</comment><comment><USER15> Did anyone else actually try this? I thought the differences were quite noticeable. I ran it through Foobar 2000's ABX Comparator and I got the right answer 5 out of 5 times.

</comment><comment><USER28> "My God! What has sound got to do with music!" ~ Charles E.Ives ([https://en.wikipedia.org/wiki/Charles_Ives](https://en.wikipedia.org/wiki/Charles_Ives))

(and I'm inclined to agree)</comment>


Why The Clock is Ticking for MongoDB - <AUTHOR> http://rhaas.blogspot.com/2014/04/why-clock-is-ticking-for-mongodb.html <comment><USER2> Having used mongo in a professional context, I'm sort of amused by how much vitriol it gets. It has it's flaws, but it's not _that_ bad. I think it's been a bit misbranded as the thing you use to "scale", which ticks people off. To me, when I use mongo, I mostly use it because it's the most _convenient_ option. It's very easy to develop against, and awesome for prototyping and a lot of times it's good enough that you never need to replace it after the prototype phase.

Relational databases are great, but they're almost an optimization -- they're way more useful after the problem set has been well defined and you have a much better sense of data access patterns and how you should lay out your tables and so on. But a lot of times that information isn't obvious upfront, and mongo is great in that context.

<comment><USER3> > Relational databases are great, but they're almost an optimization -- > they're way more useful after the problem set has been well defined and you > have a much better sense of data access patterns and how you should lay out > your tables and so on. But a lot of times that information isn't obvious > upfront, and mongo is great in that context.

I think it's exactly the other way around. I prefer to lay out tables in a way that reflects the meaning and the relationship in the data. Only later, if there is a bottleneck somewhere, I might add a cache (i.e. de-normalize) to better fit the specific data access patterns that were causing trouble.

<comment><USER4> You missed the point.

Since most companies now are doing Agile development there isn't the big upfront design process where the data model is clearly understood at the beginning. Instead you have this situation where the schema is continually evolving week by week and hence this is why schema less systems can be appealing. It isn't about performance.

<comment><USER5> IMO, this is the worst argument. There are multiple schema evolution tools for SQL, there's nothing stopping your team from changing the schema every week - plus, it's not hard, certainly less hard than having to maintain code that deals with multiple document schemas at once.

<comment><USER4> The point is that if you using an ORM and have domain classes then it is unnecessary and annoying step. You have to make changes in two places rather than just one. Most people using MongoDB I know are seasoned enterprise Java developers and we have used many schema management tools for the last decade. It is a giant relief to be finally rid of them.

<comment><USER5> IMO, it sounds like the wrong remedy for the right diagnostic. I would never throw away the database because I'm duplicating information between ORM and domain classes. This seems more related to the particular constraints imposed by your codebase/architecture than the database.

Right now I'm writing a REST API that will be consumed by web and mobile apps. It would impractical to duplicate validation across all codebases. Rather, I'm leveraging the database checks to get form validation on all clients for free. The application layer is thin, adding a field amounts to adding one line and running a command.

I believe it boils down to which component rules the system: application or data layer.

</comment></comment></comment></comment></comment></comment><comment><USER6> I really don't see how a fixed schema is seen as such a bad thing by many NoSQL advocates. In most databases, altering a schema is an operation that's over quickly and in many databases it's easily reversible by just rolling back a transaction.

The advantages of a fixed schema are similar to the advantages of a static type system in programming: You get a lot of error checking for free, so you can be sure that whenever you read the data, it'll be in a valid and immediately useful format.

Just because _your_ database is bad at altering the schema (for example by taking an exclusive lock on a table) or validating input data (like turning invalid dates into '0000-00-00' and then later returning that) doesn't mean that this is something you need to abolish the schema to solve.

Just pick a better database.

<comment><USER2> Well, I think the static typing analogy pretty much cuts to the heart of it. I wouldn't be shocked if static typing advocates tend to like relational databases, and dynamic typing advocates tend to favor nosql. (I can't prove this -- but I wouldn't be surprised).

<comment><USER4> Nope. MongoDB is very popular in enterprises which are largely dominated by Java i.e. strongly typed. MongoDB actually suits strongly typed languages since you enforce your domain in code rather than in the database.

And since Morphia ([https://github.com/mongodb/morphia](https://github.com/mongodb/morphia)) is similar to JPA it is trivial to port your existing code to MongoDB. Which then leaves you with the same experience as an SQL database except with a lot of benefits (single binary, easy to query/administer/scale, geo spatial features etc).

<comment><USER7> I'd not count Java as a sign that people at a place like strongly typed systems: Java is a default. The typing system has so few features, it pales in comparison with the alternatives. Those that are in a JVM and really care about a type system might be using Scala instead.

</comment></comment></comment></comment><comment><USER8> "This is not to deny that MongoDB offers some compelling advantages. Many users have found that they can get up and running on MongoDB very quickly, an area where PostgreSQL and other relational databases have traditionally struggled."

A few things about this I've never understood.

1\. Someone's going to make a technology decision with priority given to a one-time cost over the strengths and weaknesses of running competing products in perpetuity? The ability to avoid having to learn something is a pro in this decision?

2\. If you don't have the skill set to install or maintain MySQL or Postgres, you should not be in charge of installing or maintaining production systems, period. You will hit your ceiling the first time you have to do anything non- trivial with a system that happens to have been easier to "get started with."

<comment><USER9> The critical point in the life of a startup is very often that short period at the start, when the team is small and stretched in a hundred directions, trying to 'execute' on everything at once. It's really important to choose your battles.

Where I work (wavo.me), we went with MongoDB, and though imperfect, it was the right DB for us. It's quick to get going, and the schemaless document store makes it easy to change directions and iterate very quickly. That was (and still is) super important to us. It's really not about skillset, it's about cycles.

<comment><USER8> My point is that MySQL/Postgres aren't difficult and this is a pretty low- hanging fruit example of a decision that doesn't need to be made and shouldn't be made with short-term thinking. Maybe it's necessary at times, but you can go too far with that excuse. Code is much, much easier to change/fix than a data store.

<comment><USER4> MySQL/Postgres aren't difficult but they are more complex that MongoDB.

And in Agile you are taught to only focus on the short term and then move only when you need to. In which case picking the simpler database has merits.

<comment><USER10> It's a case where your short-term choice leads to long-term pain if you actually _succeed_ in your start up.

Should you really be making short-term decisions like that if you're not planning to fail?

</comment></comment></comment></comment></comment><comment><USER11> I can't really speak about Mongo, but since the post seems to be talking about relational vs. document based DBs in general, here's my perspective coming from CouchDB:

\- Schemaless DBs make sense, when handled correctly within the application framework, for what I'd call information systems with regularly changing requirements. I'm currently building a rapid development platform for these kinds of systems, where users can define an arbitrary relational data model from a Web-UI and get the application with forms and views all pre-made. The user design is changeable at any point without breaking anything and even the underlying static data structures can be changed without any need for an update or data migration process - it's all handled when opening or saving a document with a previous version.

\- CouchDB's map/reduce view definitions are interesting when designing a DB system, since they IMO restrict the developer in exactly the right way: One is forced to write the right kind of index views instead of being able to just join willy nilly. Making something slow usually means writing complex views and chaining many lookups together - one has to work for it and, conversely, being lazy and reducing everything to the simplest solution usually results in a fast solution as well. The result usually scales up to a high number of documents in terms of performance.

\- Being able to replicate without any precondition, including to mobile devices with TouchDB, is a big plus - and in fact a requirement in our case. Offline access is still important, especially in countries where people spend a lot of time in trains or for systems that manager types want to be accessing in flight.

<comment><USER12> > Schemaless DBs make sense ... for some cases

I think his real point is that on a SQL database like PostgreSQL you can add schemaless parts to your data if you think that it's right for your case, and with other DBMSs "capabilities in this area are improving rapidly".

But starting with a "Schemaless db" it's much harder to go in the other direction. "The advantages of relational databases are not so easily emulated."

<comment><USER11> Yes, that point is true - it's easier to go from the stricter environment to the more open one - I guess that's basically just how entropy works. Note that I don't necessarily disagree with the article, I just wanted to offer some perspective on why I think the schemaless approach can often make sense, especially in how CouchDB handles it. If at some future point, the worlds of RDBMS and NoSQL fold into one DBMS handling all the use cases perfectly, I'm all for it - it's just that right now I'm still skeptical about going all schemaless on an RDBMS, since it's still a rather new feature, and the underlying system is very complex and has grown for decades.

</comment></comment></comment><comment><USER13> This is clearly a flamebait title. The article doesn't say anything about why MongoDB is running out of time other then "PostgreSQL is making real progress as a document store". I think unwittingly the author has identified why MongoDB is not running out of time. It still has a huge lead on RDBMS in a very common and useful workload. If they can continue to make progress while other engines catch up with some of the document oriented features ( as Postgre has done ) then they will still have compelling features to offer. If they do nothing while other engines make progress then of course they will fail.

If anything all this points out is that Document stores, like MongoDB, have a real market where they excel and other engines are playing catchup.

<comment><USER14> The flame bait title was in response to a similar title on zdnet: "MongoDB chief: Why the clock's ticking for relational databases"

The author should probably have quoted that title rather than expecting people to follow the link.

</comment></comment><comment><USER15> As I always say when these sorts of articles come out (and I admit this is _my_ use case for MongoDB and that doesn't necessarily match everyone else's use case), where is the easy to setup HA and sharding for PostgreSQL? I know it's coming, but right now it's not there.

For someone who redistributes a product that relies on end-users setting up HA, this for me is MongoDB's killer feature, easy to configure replication and sharding. I _love_ PostgreSQL, but this is the one big thing that keeps me from using it right now.

</comment><comment><USER16> Often when I read articles like this I take them with a grain of salt. A lot of hate for MEAN technologies seems to stem from people who don't know how to properly use them. You're not supposed to use MongoDB like *SQL and if you try you're gonna have a bad time.

Let's say I have a big pick-up truck I use to haul xWidgets. My friend gets a little motorized scooter to drive around town hauling his yWidgets. Is it proper for me to believe that my friends scooter sucks because it doesn't haul xWidgets like my truck? I don't know much about scooters, but by friend says it doesn't have a steering wheel and it only has two wheels. How the heck can it steer without a wheel? He says it has "handle bars" for steering. Seems kind of dumb but I guess it works for him. He touts the fact that he gets 80mpg on gas but it doesn't matter how efficient it is if he can't haul xWidgets. Scooters suck because they don't work the way my truck does.

<comment><USER17> Okay. What does this have to do with MongoDB, though? People in this thread have presented plenty of usecases for it, but every single one of them (pretty much--someone correct me if I'm wrong) is also satisfied by jsonb in Postgres 9.4, which in your analogy would make it a truck that gets 85mpg.

</comment></comment><comment><USER18> My personal "big picture" critique of MongoDB is that I see it evolving into a SQL database with a different syntax. It is a strongly-consistent, distributed-through-replication-and-sharding system. Additions to 'traditional' databases, like Postgres' HStore or MySQL's HandlerSocket show that many of the MongoDB differences are not fundamental.

Much more interesting to me are systems that do something fundamentally different. e.g. explore different parts of the CAP trade-off, like Cassandra. Or systems that are built around the idea that data no longer lives exclusively on a server, like CouchDB.

<comment><USER19> I think I disagree with you on a few points. MongoDB might be adding features of SQL databases, and heading in that direction, but they are still missing joins, and that's a crucial part of relational databases.

Also, I'd clarify a little by saying it's _trying to be_ a strongly consistent, distributed through replication and sharding database. Right now there are some bugs in the system, some improvements that need to be made, and definitely some default configurations that need to be changed before it's going to be a consistent database. It's definitely going for consistency instead of availability, but I don't think it can call itself consistent yet.

<comment><USER18> I don't think we disagree as much as you might think!

I'm trying not to critique MongoDB today, but rather thinking of what it will become. Today's implementation problems will hopefully be fixed.

I agree that without joins, MongoDB querying is very limited. I credit them enough to believe they will end up fixing that and supporting joins in some way. But then, they have "SQL with a different syntax".

And I definitely agree on the data-loss bugs. But again, presuming they fix those, they just end up with something very similar to a relational DB, in terms of the CAP theorem etc.

In short, even when/if they fix all the bugs and add all the missing features, I worry that we'll just end up back where we started.

</comment></comment></comment><comment><USER20> I agree that document-oriented databases will probably not replace relational databases in the near future. In my opinion though, the schemaless design of MongoDB paired with its ease of use and its native support of JSON data makes it a perfect choice for prototyping and (in some cases) a viable option for use in production.

What you also have to consider when comparing document-oriented to relational databases is that the former is still a very young technology: MongoDB has been founded in 2007, whereas Postgres has been around since 1986! So given what the MongoDB team has achieved in such a short time span, I expect to see some huge improvements in this technology over the next decade, especially given the large amount of funding that 10gen received.

In addition, the root cause for most complaints ("it doesn't scale!", "it loses my data!", "it's not consistent!") is that people try to apply design patterns from relational databases to MongoDB, which often is just a horrible idea. Document databases and relational databases are very different beasts and need to be handled very differently: Most design patterns for relational databases (data normalization, using joins to group data, using flat data structures, scaling vertically instead of horizontally) are actually anti- patterns in the non-relational world. If you take this into account I think MongoDB can be an awesome tool.

<comment><USER21> To be fair this particular complaint:

> "it loses my data!"

is entirely legitimate. A database product should not be losing data unless you specifically allow it to. Period.

<comment><USER22> There's cases where occasional data loss is an acceptable trade off for performance. In a particular app I'm working on it's ok for me to have 99.9% of the data and all my updates and inserts have write concern set to 0, journaling off, etc.

<comment><USER21> Sure, hence:

> A database product should not be losing data unless you specifically _allow > it to_.

</comment></comment></comment></comment><comment><USER23> I've been asking a lot of people when MongoDB is actually the right tool for the job.

[http://daemon.co.za/2014/04/when-is-mongodb-the-right- tool](http://daemon.co.za/2014/04/when-is-mongodb-the-right-tool)

I'm starting to form this idea of what constitutes an ideal use case for mongo in my head, and i'm trying to prove the model.

If I were to imagine some kind of "realtime" multiplayer game, like quake or something.

1\. You have to have the state be shared between all the parties in a reasonable time.

2\. The clients only need the data that is directly relating to the round they are in, so you have the concept of cold and hot data.

3\. The data is all kind of ephemeral too, so that you don't specifically care about who was on what bouncy pad when, but you do want to know what the kill score/ratio is afterwards.

4\. You have a couple of entities that have some kind of lightweight relationship to each other, which makes it just more complex than a key-value store like redis is really suitable for.

5\. These entities are sort of a shared state, and thus get updated more often than new unrelated documents get added, and couchdb's ref-counting and append- only nature makes it really unsuited for constant updates of an existing record.

any feedback would be appreciated.

<comment><USER24> This seems totally reasonable to me. I was playing around with using Firebase ([https://www.firebase.com/](https://www.firebase.com/)) as the datastore for a turn-based multiplayer game on the web and its data policies seemed very well suited.

Essentially, each game was its own document and relevant stats were updated/duplicated on the player documents as well.

There don't seem to be useful relationships here that I'd want to query. _Maybe_ successive game states? But not across different games, right?

<comment><USER23> Well, I was imagining a situation where you had multiple different pieces in a game, relating to each player and distinct to that game. Maybe like an RTS game or something?

So you might want to query how many pieces a certain player has available, or do a check on who this piece belongs to.

Keep in mind I'm still not saying an actual game, but any problem that had similar data storage and access patterns as a game along these lines would have.

I don't know enough about firebase to confirm whether it is suited to this, but if I had any kind of backend at all, and I had requirements for really quick reponses, i wouldn't be comfortable adding the extra hop to a hosted service onto each call.

</comment></comment></comment><comment><USER25> From reading Redmond & Wilson's book "Seven Databases in Seven Weeks", my impression is that the CAP Theorem is a big idea (essentially, you get two choose any two: consistency, availability, and partition-tolerance). Relational databases have to be "consistent", i.e. transactions are atomic and reads always get the latest value. NoSQL databases make it possible to choose Availability instead of Consistency, so you can get faster response times even if it means you sometimes get out-of-date data.

I would use Mongo or Riak or something like those for "write once, then read- only" applications, for example a twitter or facebook type application, or simple blog. In those cases when the user hits "refresh" they're never going to know or care that they don't yet see a comment someone posted a half second ago. They're just going to be happy that the page refreshed fast.

</comment><comment><USER26> Given the title I expected a completely different article. The reason being that the opinion that "MongoDB is running out of time" can be supported by a few very strong arguments. There are a few very serious problems with the current technology that give NoSQL alternatives a chance to catch up and grab momentum. For example, MongoDB still has a questionable mmap based storage engine, there are cluster state consistency issues, the cluster topology management is outdated and so on. This article should have been titled "Why I personally like relational databases better than MongoDB". That discussion is incredibly subjective. Source : Very early adopter of MongoDB and use it professionally.

<comment><USER25> It was a play on the title of the article that the author was responding to.

</comment></comment><comment><USER27> I think many folks confuse normalization as a strategy with the underlying database technologies. Oracle and other RDMBS technologies can create normalized databases too. In the end it's a design judgment. There is a lot of room between fully normalized and one-big-table. Even firms that logically map things out fully normalized frequently decide that for some things that doesn't make sense.

Taking a step back, there are still reasons to abandon Oracle. It may not scale up, or be good for certain time series calculations, but that's another story entirely.

</comment><comment><USER28> It´s funny to see this kind of posts now and then predicting the close end of mongodb... for several years now!

MongoDB is here to stay. It´s opinatred, PostrgreSql isn't. It's faster out of the box. The client drivers are pretty good. (Dont forget that SQL database still send raw text as request and get raw text in return!). It's fitting the bill for a lot of quick and dirty web apps and deliver early performance and argualy scalable performance. Dont get me wrong, I still litteraly love postgres.

<comment><USER29> > It's faster out of the box

...for reads. Once you get any _real_ traffic it hangs on its DB write lock. Yes, I have experienced this, and the solution "just shard!" is especially obnoxious because setting up sharding is a lot harder than they make it seem. Not only is it complicated, you go from one server to three config servers, two repsets with 3 servers each (so 9 fucking servers) just so you can make more than 40 writes/s that most relational DBs wouldn't bat an eyelash at.

It's a poorly designed system, and this becomes painfully apparent once your app moves out of the basement and into the real world. Luckily for MongoDB, most of their users' apps never leave the basement and they think "wow, this is great!!"

> argualy scalable performance

Not scalable. At all. Global locks do not scale. Complicated config setups are hard to scale.

Check out RethinkDB. It's an open-source document DB that fixes just about all the problems MongoDB has _and_ it has DB-side joins. It's just as easy to get quick and dirty apps running against, and it doesn't actively flush your data down the toilet like Mongo has been known to do.

</comment></comment><comment><USER30> Dramatic titles get the readers attention, therefore I get the choice of words. However, our industry is so big that there will never be a single solution. MongoDB may never become #1 but as it's described in many comments, it's a pretty good choice in various situations. So, as they say in Ireland "Stall da beans der bi!" I don't hear a ticking clock.

</comment><comment><USER31> On document store indexes the article says:

> If all order data is lumped together, the user will be forced to retrieve > the entirety of each order that contains a relevant order line - or perhaps > even to scan the entire database and examine every order to see whether it > contains a relevant order line.

Both of these are untrue. Author needs to read up on secondary indexes.

</comment><comment><USER32> Maybe the clock is ticking because thier large production deployments are migrating to other tech? At least we are seeing plenty of folks who realize that a query API on top of mmap isn't really a database. :)

One high profile migration: [http://www.couchbase.com/viber](http://www.couchbase.com/viber)

<comment><USER4> MongoDB will be shipped as part of every RHEL installation. So pretty sure it is actually going to be getting even more popular.

</comment></comment><comment><USER33> The author is conflating (or just ignoring) the very significant difference between application databases and reporting databases. Not surprising since most of us do this as well when we are building applications. However no comparison of the relative value of database schema styles can responsibly ignore this difference.

</comment><comment><USER34> _In short, I don 't expect MongoDB, or any similar product, to spell the end of the relational database._

The author makes it sound like that was a possibility. SQL and NoSQL are two different tools in the toolbox and should be considered as such.

</comment><comment><USER35> Man, how long has it been since MongoDB has supposedly been dying? I swear it's more than 3 or 4 years for sure.

</comment><comment><USER36> Actually, graph databases are better suitsd for many of today's social applications.</comment>


CSS Basics (Part I, Animations) - <AUTHOR> https://dev.to/bensassialadin/css-basics-part-i-animations-5ie <comment><USER2> Where is a good place to learn what an "@keyframes" is?

<comment><USER3> Google, w3c, mdn... to name a few

[https://developer.mozilla.org/en- US/docs/Web/CSS/@keyframes](https://developer.mozilla.org/en- US/docs/Web/CSS/@keyframes)</comment></comment>


Ask HN: Need feedback on my first own iPad app – Coloring book with some magic - <AUTHOR>

App website: http://happycolorsapp.com/ App in AppStore: http://itunes.apple.com/us/app/id476232119?mt=8
I'd especially like to get feedback on some drawing magic: when you draw inside some area – you won't go out of borders.
Promo codes (request more in comments if these doesn't work):
EYK33NM7MNFR MAFXJR7EAN7F 7FAHEXERM9F7 MN7N7WLR3RJ6 7E36KF3MFTX7 <comment><USER2> Can I offer some suggestions on the site copy? All meant constructively.

Draw with a finger It's the paintbrush we all have. Scary Colors lets your kid finger paint on screen. Just as fun, but far less messy.

Special Scary Edition Right now it's Halloween, so there are 30 spooky pictures to color in. More pictures will be available soon.

Share your kid's masterpeices Easily send their colored pictures via e-mail and share them on Facebook with family and friends.

We provide some magic All the fun of finger painting, but the color stays inside the lines, just try it. (You can also turn off the magic to test their skills.)

<comment><AUTHOR> Great, thanks for suggestions. Will update copy a bit later.

<comment><USER2> Glad you liked them. Best of luck with the app.

</comment></comment></comment><comment><USER3> Quite nice, might need a few more options/tweaks.

For younger kids, you might want to have fewer colors, and make the color circles on the palette bigger. It would be nice if the interface rotated on page where you choose the photo. And a way to clear the photo completely, as opposed to having to paint it all in white. I looked for an undo button, but I think it was just reflexive... you probably don't need it. Something that looks like an eraser might be good for kids, as opposed to painting with white. And maybe a few more drawings with big blocks to color and less small nooks to fill (hard for kids).

Overall, great MVP.

<comment><AUTHOR> Thanks, I'll think on adding eraser and possibly other tools in next updates.

</comment></comment><comment><USER4> Thanks for the test run. a few comments: \- while having the enforced borders certainly will enhance a child's ability... maybe have a toggle to disable it? drawing inside the lines is more of a skill development device for children. \- maybe explore ways to improve the drawing tool? penultimate's ink-like quality looks and feels great. maybe faster motions make a larger stroke than subtle movements?

best, mike

<comment><AUTHOR> Good idea, I rushed to release MVP, but I also think it will make sense to have different modes.

</comment></comment><comment><USER5> That's an awesome first attempt. Definitely amazed at the polish of it all. Would you mind letting me in on your secret on how you got it so polished? I'm a developer so I haven't a clue how to make it look as nice as you have.

P.S. Don't have my iPad with me but I'll let you know when I do get home.

</comment><comment><USER6> can you add more test codes, thnx

<comment><AUTHOR> NML3FK6WLLP9 NWRMPEYHYMJH PM99WRA47NEY LPWAE9NWNPR7 JEHNTWRKNNLF</comment></comment>


As Digg Struggles, VP Of Engineering Is Shown The Door - <AUTHOR> http://techcrunch.com/2010/09/07/digg-struggles-vp-engineering-door/ <comment><USER3> Like Joel Spolsky said it: "They followed the single worst strategic mistake that any software company can make: They decided to rewrite everything from scratch" - <http://www.joelonsoftware.com/articles/fog0000000069.html>

I think rewriting from scratch is the core of their problem and not really Cassandra. Gradually going over to Cassandra would have been a much better idea.

<comment><USER4> I've heard this time and time again, but what if your application is a genuine ball of mud? Would you really not advocate a rewrite for an unmaintainable spaghetti classic asp app still in production today?

<comment><USER5> Microsoft could be one example of a successful one. Their flagship Windows codebase that ran the 3.1->95->98->ME line was basically ditched with the rewrite-from-scratch NT (famously done by an ex-VMS team), which later had some APIs ported to it to make Windows 2000 and especially XP be close to drop-in replacements for the old line, while not really sharing much code. I think in retrospect that was probably a good idea: the NT rewrite put the codebase on much better footing than the aging, incrementally updated classic Windows codebase had been.

Solaris is another example of a rewrite that seems to have worked, though the rewrite did derive from a different set of existing code, not a total from- scratch job. But the classic SunOS 1.x.-4.x codebase was ditched, and SunOS 5.x / "Solaris 2" replaced it.

<comment><USER6> You covered Windows and Linux - don't forget Apple's switch to OS X. They wouldn't done a wholesale switch at some point even if they hadn't gone with something unix-based because the other alternative was Copeland, the internal project to do a complete rewrite.

<comment><USER6> EDIT: they _would have_ made the switch. Stupid iPhone.

</comment></comment></comment></comment></comment><comment><USER7> Is there any reason that Cassandra is the focus of this article? It is really silly and irresponsible to peg a nascent project like that without any reasoning or sources. I'm sure something changed besides just a Cassandra rollout, and wasn't Digg using it on v3 too?

I think Cassandra is pretty well tested. There have been lots of super-large- scale deployments. It just seems lame to blame it on that, but I guess maybe their anonymous sources inside Digg revealed it? But then we'd hope they'd know if the problem was with the datastore or the implementation.

<comment><USER8> Placing all the blame on Cassandra helps Digg justify letting go the VP, since he was allegedly the guy who pushed it.

<comment><USER9> So what's the digg story here?

I get that some VP suggested a new buzzwordy technology, they gave him enough rope to hang himself and he did and left the company with a broken pile of crap. It could happen, if you have a healthy company you give trust to people. That it got this far doesn't speak well of the rest of management. It doesn't speak really well of the rest of the team either. Shouldn't there have been some circuit breakers or something?

Digg isn't a poor, bring-your-own-laptop startup. They've got resources, they've had substantial investment. They can afford to build and test software and I know of no real marketing reason they had to push something untested out. Rose could go out and say it wasn't done, it's going to take more time.

How does Rose keep his job? Wasn't he this VP's boss?

And it's single technology? That couldn't have been vetted and tested independently of all of digg? Really? And MongoDB, or hadoop, or one of the dozens of other nosqls wouldn't work, either? You do what you have to do and there is never a 'truth' with VPs and CxOs are canned, but it all doesn't float with me, just looks like another over valued and under talented company, got lucky and the blind squirrel found the nut, there isn't gonna be a second act.

Maybe it just seems low brow to me, name and finger the guy, blame the opensource tool you use, never explain or elaborate why you launched anyways when you were fixing bugs in the tool at the 11th hour.

<comment><USER10> I'm sure the real story is different. My rough guess at it is

* the main marketing tool that digg has left is "Kevin Rose as genius"

* Kevin and the people he drinks with pushed for the adoption of new cool technology.

* the entire thing was a giant clusterfuck because of Kevin and the people he drinks with.

* but once that became obvious there was a need for a scapegoat so that digg could keep its primary marketing tool.

<comment><USER11> That reads like sour grapes.

<comment><USER12> Reads like "industry experience" to me.

<comment><USER13> Perhaps it's both?

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I actually wondered if they were running into issues with Cassandra. I'm not a NoSQL hater - but its still pretty bleeding edge and it always seemed like making it your core db was super risky.

arg - really want more insight, maybe Quinn will elaborate now that he's gone.

</comment><comment><USER15> Digg's put out a lot of information about their Cassandra implementation, eg <https://nosqleast.com/2009/slides/sarkissian-cassandra.pdf> (from November 2009).

Back then they seemed to have a rather sensible migration strategy (ie, basically running the new Cassandra back-end in parallel with the MySQL backend).

It seems to me that it was the v4 upgrade that broke, not Cassandra alone. It's possible their frustrations with Cassandra were more long term, and the fact the v4 upgrade didn't go well was the last straw.

For example, Digg has done a lot of work on Cassandra internals and tools. If you are using a new, open source product you kind of expect that, but it's possible the expense of that didn't seem like good value once v4 started to get into trouble,

</comment><comment><USER16> For some reason this reminds me of the "no one has ever been fired for choosing IBM." slogan. I guess maybe there is some truth to it. Seems like new tech needs to start slow on big places, only startups really have the freedom to risk it all.

<comment><USER17> your post implies digg isn't a startup.

<comment><USER18> Digg isn't a startup. It started in 2004 and has been mature for about 5 years. They are a business now. And a big one at that.

<comment><USER19> That depends on how you define your terms. I'm not sure a company that has been around 6 years and has ~100 staff can be called a startup any more. On the other hand, I'm not sure a company that still survives more on the wishful thinking of investors than on the money it brings in after 6 years can be called a business, either, and certainly I wouldn't call it either big or mature. I'm honestly not sure what I _would_ call that sort of organisation, though if I were an investor, I suspect the word "liability" would feature somewhere.

<comment><USER20> > I'm not sure a company that still survives more on the wishful thinking of > investors

Unless you are owned by a larger company that runs you at a loss as part of their strategy. Or stragedy.

</comment></comment></comment></comment></comment><comment><USER21> This man's reputation is on the line. I hope they release more details on what exactly it is that is causing the problem. As it stands he appears to be an unfortunate scapegoat.

<comment><USER22> Hopefully he creates a blog post explaining the disaster. He seems to regularly update that site

</comment></comment><comment><USER23> Digg turned into nothing but a paid distribution and SEO engine anyway

<comment><USER24> Digg was something else before?

<comment><USER25> Yeah originally it was Slashdot but better, more current and user powered (which was a new concept in the mid 2000's). What it turned into was a traffic generator for a small group of power users who fed the community the lowest common denominator of content.

<comment><USER26> User powered will always turn into lowest common denominator if the user base grows beyond a niche

</comment></comment></comment></comment><comment><USER27> Reddit runs on Cassandra + PostgreSQL. They use Cassandra as a key/value store and not as the primary database though.

<comment><USER7> They are planning to transition to Cassandra as the primary database. PostgreSQL is not used in a relational way on reddit -- it is used as a makeshift k-v store. You can take a look at this yourself as reddit is fully open-source: <http://github.com/reddit> .

<comment><USER28> > They are planning to transition to Cassandra as the primary database.

do you have a source for that ?

> it is used as a makeshift k-v store

That is very true, they should switch. It just seemed like they had no plan to do so.

<comment><USER29> I could swear an admin said it with some pretty fair definitiveness; I thought I remembered that it was ketralnis, but this was the best I could find from him, and it's not nearly as definite as my memory says.

[http://www.reddit.com/r/programming/comments/bcqhi/reddits_n...](http://www.reddit.com/r/programming/comments/bcqhi/reddits_now_running_on_cassandra/c0m3rs9)

</comment></comment></comment></comment><comment><USER30> This article is a fine example of the poor logic that pisses me off nearly every day. Just because Digg v4, which heavily uses Cassandra, can't be used as a Cassandra success story does not automatically mean you can assume the opposite, that it is a Cassandra failure story. There is no indication why Digg has been down so often and there is really no conclusions to draw as of yet on the technology they use.

<comment><USER31> The article basically comes right out and says it. You just need to read between the lines a little bit.

From the article: Quinn was the main champion of moving over to Cassandra, say our sources. Now the site is taking a huge hit, at least in the short term, because of that decision and/or how it was implemented, and Quinn is paying for it with his job.

It's always a toss up between whether it was implemented correctly or not. The correct course of action of course would have been to slowly move the site over to the new technology piece by piece rather than a wholesale switchover. The risk is in the migration strategy not the technology picked. They could have been equally stupid switching over to a new architecture with mysql.

<comment><USER26> I'm not sure I'd use tech crunch as a reliable source.

</comment></comment></comment><comment><USER32> Reddit went through similar issues a few months back (downtime, slowness, etc.), but they overcame these issues without turfing people. My guess is Digg pushed the engineering VP out to make the investors happy rather than to actually move forward.

<comment><USER33> How does it make investors happy? Why would investors care what kind of database you use?

<comment><USER34> it's an attempt to control the PR message.

by doing this, they are laying the blame on one person so the media can stop hating Digg and start hating the ex-VP of Engineering who "killed Digg".

of course, whether he was actually responsible in some way is something we may never know. for all we know he may have been completely against releasing v4 but was vetoed by Rose et al. or on the other hand he may have overpromised and under-delivered, putting the company in jeopardy, in which case he deserves to be let go.

it's all speculation until we hear an official comment from either side.

</comment></comment></comment><comment><USER35> Unless Digg cannot roll out new features due to Cassandra (eg: a) Cassandra woes taking all dev team time, or b) tech limitations prevent features) it seems highly unlikely that cassandra is the reason why Digg 4 is grating with users initially.

It's a change of features/product rather than technology that is the problem.

<comment><USER36> I think the folks at Digg where prepared for the heartburn associated with the content changes. They weren't ready for some very serious issues with the implementation. Digg has definitely seen a lot of downtime over the last week or two.

</comment></comment><comment><USER22> I'm really interested to see what comes of this and what went wrong. It sounds like (from reading his blog) they were making a lot of customizations to Cassandra?

<comment><USER37> They have made many feature additions to Cassandra.

They haven't said much about the details of why they are having trouble.

It could be a core Cassandra problem, something they added, or completely unrelated to Cassandra; But the internet doesn't care. It's drama at its finest.

<comment><USER38> "It could be a core Cassandra problem, something they added, or completely unrelated to Cassandra; But the internet doesn't care. It's drama at its finest"

Digg made a _big deal_ about their move to Cassandra (just as Digg's move to Cassandra was used to legitimize Cassandra, and by correlation NoSQL, among a wide range of zealots), going back over a year.

The thing about talking big like that is that it often comes back to bite you in the ass if things don't go well.

If Digg quietly released a new version that worked more reliably and provided a better experience, they would have been in a perfect position to pontificate on technology.

</comment></comment></comment><comment><USER39> Ok Digg is having a hard time. I feel like I witness a strange blood thirsty tone in some of the comments though. I wish Digg the best and I hope they can prove all the skeptics wrong. It's going to be tough though!

</comment><comment><USER40> I wonder what issues they are running into that a dark launch would not have found. As I have discovered painfully in my own projects, making big changes without a rollback plan is usually a bad idea, and it sounds like this is no exception.

<comment><USER41> Yeah, it sounds like the launch process is more at fault than the technology for this if there's really no way to rollback to stability.

</comment></comment><comment><USER42> Digg v4 has added back the features I liked after taking them away - <USER2> the Upcoming section, which tends to have interesting things that never make it to the front page, and the setting that allows you to default to Top Mews, instead of things I have already read ('My News').

For most users, change in features is what drove them away, not necessarily the spotty QOS (though that was pretty bad for a while).

</comment><comment><USER43> I have to say I like the new Digg. Sad this guy is getting his career stomped on over it. Lot of people complain that the new site lets big sites submit their own content automatically, but how was it any different with a middle- man user submitting it himself?

<comment><USER44> The real problem is that v4 removed the illusion that average users had an influence on the rankings, without altering the fact that they don't.

<comment><USER45> Yeah, I may be blind, but how do you even get to the upcoming stories?

<comment><USER44> You can't right now. It's on the list of things they haven't finished reimplementing from v3.

</comment></comment></comment></comment><comment><USER46> Digg 4.x is like Star Wars Galaxies NGE.

</comment><comment><USER47> Let me guess - the problem is about the difference between theory and practice.

In theory, Java is great and Cassandra is great. In practice - Java under a heavy load is a disaster, because it was never designed for it, and Cassandra is a just a hype and propaganda.

Face the reality - it doesn't work in production as it supposed to - as a primary storage engine.

People at the Digg aren't amateur idiots, so I think they do everything as it described in docs, but the damn thing just doesn't work.

<comment><USER15> > In practice - Java under a heavy load is a disaster

Google's heavy use of serverside Java would indicate otherwise.

> because it was never designed for it

Yes it was. Java has a lot of problems, but one thing that isn't a problem is heavy load.

> Cassandra is a just a hype and propaganda

Facebook seems to be using it ok.

<comment><USER47> Google probably use server side Java without a really heavy load, and just add more servers to keep the load low.

System which was designed for being isolated from an OS (leave alone hardware) will have a bottleneck exactly in this level.

Facebook doesn't use it as a primary storage with a high load.

<comment><USER48> What would you prefer to write web applications in? C++?

Most languages used in web programming are divorced from the hardware, and either use a virtual machine (e.g. Java, .NET) or an interpreter (PHP, Python, Perl, Ruby).

Virtually no-one uses a low level language for web programming, and the benchmarks say that the virtual machines are faster than interpreters. Java is very fast and efficient once it's running, but initial start-up time is often slower than interpreted languages due to the JIT compilation, but servers rarely "start up". If you're really hitting a barrier with Java's performance, just as with other non-native languages, you can write the performance critical section in C.

[http://shootout.alioth.debian.org/u32q/which-programming- lan...](http://shootout.alioth.debian.org/u32q/which-programming-languages- are-fastest.php)

</comment></comment></comment></comment><comment><USER49> Queue NoACID haters declaring this the final nail in the coffin.

<comment><USER50> This isn't Digg.</comment></comment>