Why is it unproductive? If I am trying to decide for my home desktop whether I want to get a SSD or a HDD, what do I do? I compute the price/GB, decide how much stuff it's worth to put on SSD based on that, and then order based on that. If the price differential was 5x instead of 15x, that would make a huge difference in what I buy.
I really don't understand why you say that comparing the price/GB is unproductive.
I'm not the publisher, so you'd have to ask them. My intuition is that a downloadable e-book (like e-pub format) would be a bigger cannibalization of the sale market than a good PDF that was formatted for normal-sized paper (or the larger-than-letter size that, IIRC, the Feynman lectures are printed on). I doubt they'd be willing to do a DRM-free version, as awesome as that would be.
Though it does bring up the idea that they might be missing a possibility of putting a Kindle edition (or another DRM'd version) out based on the HTML conversion.
SSD and HDD arent the same thing and are used for different but overlapping purposes. Comparing them directly is just plain ignorance.
That's a dumb statement. To an enormous extent, SSDs and HDDs are used for different but overlapping purposes precisely because they have a very significant cost difference. In many cases -- almost certainly most cases -- the cost determines which you get (either directly or indirectly), so comparing the cost makes complete sense.
While your comparison makes sense too, it also makes sense to compare the lowest price/gb available in each medium. If I wanted a 4TB SSD, I'd just get a bunch of smaller ones and do something to join them. (Or just use lots of partitions.) Eight Crucial M4 512 TB drives can be had for ~$3200, which is 19x the cost of the SSDs.
The cheapest hard drives per-size seem to be about $40/TB (the cheapest 2, 3, and 4 TB drives are all in that vicinity). The cheapest SSDs per-size seem to be a bit under $700/TB (at four 256 GBs), and you can get a model that is probably good for about $750/GB. That's still a bit more than 10x, but it's actually pretty good for a rough estimate still.
To be fair, you get some student backlash too. Incorporating active learning techniques -- where the student has to do some work in the classroom as opposed to just listening -- into the classroom has been shown time and time again to improve long-term retention of materials, and yet if you do it as a teacher your student ratings will drop.
Why? Because "you're not teaching me" and "I had to do everything myself!", as if teachers have a magic hammer with which to pound the knowledge into students' brains.
(It occurred to me just after I hit submit that, just as I assumed that you misinterpreted me, I may have misinterpreted you and you didn't mean to say that I was, in fact, calling him a one-trick pony. If true, I apologize, and hopefully we can stop talking past one another.:-))
Also AC's comment wasn't down-voted, I was thinking of his/her parent, the originator of this thread.
And frankly calling Einstein a one trick pony shows how fucking little you know of the man's scientific achievements.
That... was kind of my point. I was addressing AC's down-voted comment that "He got lucky once and stole Olinto De Pretto's formula, but after that?" which is so blatantly BS that I called it out in... perhaps too much of an understated manner.:-)
So why can't you just print the pages out to PDF? Would the result be considered "not good quality" PDF?
Nah... a printed web page will only print even remotely close to the quality of a real typeset book if a lot of effort was expended on creating CSS specifically for printing, and even then you probably can't get even all that good. (Could you even get a table of contents with page numbers? I dunno.) And that basically means that it wouldn't happen.
Of the three, special relativity is arguably his least impressive work
Exactly. I mean, his Nobel prize wasn't even for relativity -- it was largely for his explanation of the photoelectric effect, which basically spawned quantum physics. He already had earned his Nobel before he even published E=mc^2.
Calling Einstein a one-trick pony is using an awfully liberal definition of "once".
This page says Caltech holds the copyright. Presumably they require(d) that faculty transfer copyright of works they did in the course of their employment to the university. My guess is that's probably standard provision for faculty, though I'm not positive.
rs1n and I both speculate that the reason they don't just release PDFs from the Latex source is that the publisher feels that would compromise physical book sales (and HTML doesn't).
Publish the Latex source and you're back to "publisher won't allow it" land (if our assumption holds).
My guess is that it's the "book sales would not be harmed" qualifier, with the assumption that just posting good PDFs would harm sales and an HTML version wouldn't.
I'm not sure how they got to that conclusion, but that's my guess anyway.
Sometimes, students don't like the teachers who force them to work hard and learn the material. That's why we have tenure.
Um no, it's not.
University faculty have tenure because donors to universities would sometimes force the university to fire faculty who took up controversial topics in the wrong direction.
...is this because they are inspired or is it because they make the material seem simpler (perhaps partly because they may be better teachers but also because they will not complicate matters by introducing their own cutting edge research)
Speaking as someone who just got his PhD and would like a teaching-focused faculty position in a few years, the study was looking at freshmen courses. I don't think it's a stretch to say that if you're wedging your cutting edge research into an intro class, you're almost certainly doing it wrong.
More likely is that I won't touch if it is unlicensed, because I don't know where I stand.
If it's unlicensed, it's very easy to know where you stand: nowhere, and legally speaking you have no permission to do anything with it.
(If it's on Github you have some token rights like the ability to look at the code and fork the repository -- whatever that means -- but probably don't have the right to, say, distribute it outside of Github. IANAL, YMMV.)
The thing is... 16 bits is enough, but only barely. A quiet room is about 30-40 dB above the threshold of hearing, and 16 bits gets you about 96 dB of signal-to-noise. I think it makes sense to add those numbers, and say that if you set the volume so you can just barely hear the quietest bits of a recording that covers the entire dynamic range, then the loudest parts will be at 126-136 dB. Coincidentally or not, that's actually right at the threshold of pain, which is typically quoted at 130 dB.
OK, so this is not actually quite right:
The answer: Our -96dB noise floor figure is effectively wrong; we're using an inappropriate definition of dynamic range. (6*bits)dB gives us the RMS noise of the entire broadband signal, but each hair cell in the ear is sensitive to only a narrow fraction of the total bandwidth. As each hair cell hears only a fraction of the total noise floor energy, the noise floor at that hair cell will be much lower than the broadband figure of -96dB.
Thus, 16 bit audio can go considerably deeper than 96dB. With use of shaped dither, which moves quantization noise energy into frequencies where it's harder to hear, the effective dynamic range of 16 bit audio reaches 120dB in practice... (source)
So there's rather more headroom (by about 20 dB) than I say.
However, even that link has this to say:
Professionals use 24 bit samples in recording and production [14] for headroom, noise floor, and convenience reasons.
16 bits is enough to span the real hearing range with room to spare. It does not span the entire possible signal range of audio equipment. The primary reason to use 24 bits when recording is to prevent mistakes; rather than being careful to center 16 bit recording-- risking clipping if you guess too high and adding noise if you guess too low-- 24 bits allows an operator to set an approximate level and not worry too much about it. Missing the optimal gain setting by a few bits has no consequences, and effects that dynamically compress the recorded range have a deep floor to work with.
An engineer also requires more than 16 bits during mixing and mastering. Modern work flows may involve literally thousands of effects and operations. The quantization noise and noise floor of a 16 bit sample may be undetectable during playback, but multiplying that noise by a few thousand times eventually becomes noticeable. 24 bits keeps the accumulated noise at a very low level. Once the music is ready to distribute, there's no reason to keep more than 16 bits.
so my overall point -- 16 bits is enough for the end user but not very good for mastering -- holds.
either you want the 1812 overture to be so quiet you can't hear most of it, or so loud it causes hearing damage, or you don't need more than 16 bits.
The thing is... 16 bits is enough, but only barely. A quiet room is about 30-40 dB above the threshold of hearing, and 16 bits gets you about 96 dB of signal-to-noise. I think it makes sense to add those numbers, and say that if you set the volume so you can just barely hear the quietest bits of a recording that covers the entire dynamic range, then the loudest parts will be at 126-136 dB. Coincidentally or not, that's actually right at the threshold of pain, which is typically quoted at 130 dB.
What this means is that there is little room for processing at 16 bits, or even making the recording in the first place (as you have to set the input volume so that you come close to clipping without actually clipping). Cut much more than 10 dB off the dynamic range and it'll be audible to careful listeners in realistic scenarios.
So the higher bit depth definitely makes sense for recording and mastering, just not so much for the end user. However, for a project like Musopen that is trying to make actual open recordings, it also makes sense to distribute the better recordings because they're the equivalent to source code. But like source code, most people don't get any (direct) benefit from it being available.
But yeah, the comment a couple parents up saying even 24 bits may not be enough: no. 24 bits is more than plenty.
I'm convinced that 44.1/16 is beyond human hearing ability in realistic scenarios... but it's only a little beyond it. It leaves very little wiggle room for doing any processing.
Or even just recording. 16 bits actually records slightly less than the human ear can distinguish in really ideal conditions. Those conditions are pretty much "you're in a soundproofed room" with essentially no ambient noise, but that doesn't leave a lot of room to "a good listening environment". So if you're recording in 16 bits, now you've got to worry about setting the input volume almost perfectly, so that you've captured the quiet parts but never clip. Clip? That'll be audible in even mediocre conditions unless you make up stuff. Record volume 10 or 15 dB too low? Probably careful listeners in a good but realistic environment could tell. With 24 bits? Now you've got a ton of wiggle room.
If you are going to remix it then up mix it to 192kHz before you start hacking on it.
You'll never be able to pull audio out of recordings you downloaded from this project that doesn't exist
It's amazing you managed to write both of those sentences in the same post.
Dropping from 192 KHz to 44.1 destroys information that you can never get back. It's not information that can be used if you just listen to it, but it is information that can be used if you pass it through more editing stages.
CPython is a blurry rocket of speed when compared with Jython.
Is Jython an order of magnitude slower than CPython? Because that's my rule of thumb for CPython vs C. (Actually the programming language shootout's numbers are more like 30-40x slower than C, though that needn't be representative.)
And in theory you can write all the compute-expensive routines in C++.
Sure, but then that's not Python being fast, it's C++ being fast. "You could write the expensive parts in C or C++" can be said of nearly any language.:-)
CPython is... really quite slow. You [i]do[/i] have to do something computationally intensive to notice, of course.
That point and your parent's question are actually related to the PyPy question in the interview actually. PyPy is a JIT for Python that is able to get significant speedups for computationally-bound code. They run 20 benchmarks comparing PyPy and CPython, they are faster on all 20, and see speedups ranging from about a 27% improvement to a ~30x improvement, on average running 6.2 times faster. (Link)
Slashdot Mirror
Just a couple of weeks before I was planning on building a new computer. Wonderful.
And since the most interesting, useful, and relevant piece of information was left out of the summary, prices have gone up 27% since the fire.
Aside from the fact the government and many institutions (like Banking in the US) already have your fingerprint...
Errr... what? I've never had to give my fingerprint to my bank or the government, aside from the fact that I've handed them papers that I've touched.
Why is it unproductive? If I am trying to decide for my home desktop whether I want to get a SSD or a HDD, what do I do? I compute the price/GB, decide how much stuff it's worth to put on SSD based on that, and then order based on that. If the price differential was 5x instead of 15x, that would make a huge difference in what I buy.
I really don't understand why you say that comparing the price/GB is unproductive.
I'm not the publisher, so you'd have to ask them. My intuition is that a downloadable e-book (like e-pub format) would be a bigger cannibalization of the sale market than a good PDF that was formatted for normal-sized paper (or the larger-than-letter size that, IIRC, the Feynman lectures are printed on). I doubt they'd be willing to do a DRM-free version, as awesome as that would be.
Though it does bring up the idea that they might be missing a possibility of putting a Kindle edition (or another DRM'd version) out based on the HTML conversion.
That's a dumb statement. To an enormous extent, SSDs and HDDs are used for different but overlapping purposes precisely because they have a very significant cost difference. In many cases -- almost certainly most cases -- the cost determines which you get (either directly or indirectly), so comparing the cost makes complete sense.
While your comparison makes sense too, it also makes sense to compare the lowest price/gb available in each medium. If I wanted a 4TB SSD, I'd just get a bunch of smaller ones and do something to join them. (Or just use lots of partitions.) Eight Crucial M4 512 TB drives can be had for ~$3200, which is 19x the cost of the SSDs.
The cheapest hard drives per-size seem to be about $40/TB (the cheapest 2, 3, and 4 TB drives are all in that vicinity). The cheapest SSDs per-size seem to be a bit under $700/TB (at four 256 GBs), and you can get a model that is probably good for about $750/GB. That's still a bit more than 10x, but it's actually pretty good for a rough estimate still.
To be fair, you get some student backlash too. Incorporating active learning techniques -- where the student has to do some work in the classroom as opposed to just listening -- into the classroom has been shown time and time again to improve long-term retention of materials, and yet if you do it as a teacher your student ratings will drop.
Why? Because "you're not teaching me" and "I had to do everything myself!", as if teachers have a magic hammer with which to pound the knowledge into students' brains.
(It occurred to me just after I hit submit that, just as I assumed that you misinterpreted me, I may have misinterpreted you and you didn't mean to say that I was, in fact, calling him a one-trick pony. If true, I apologize, and hopefully we can stop talking past one another. :-))
Also AC's comment wasn't down-voted, I was thinking of his/her parent, the originator of this thread.
And frankly calling Einstein a one trick pony shows how fucking little you know of the man's scientific achievements.
That... was kind of my point. I was addressing AC's down-voted comment that "He got lucky once and stole Olinto De Pretto's formula, but after that?" which is so blatantly BS that I called it out in... perhaps too much of an understated manner. :-)
So why can't you just print the pages out to PDF? Would the result be considered "not good quality" PDF?
Nah... a printed web page will only print even remotely close to the quality of a real typeset book if a lot of effort was expended on creating CSS specifically for printing, and even then you probably can't get even all that good. (Could you even get a table of contents with page numbers? I dunno.) And that basically means that it wouldn't happen.
Of the three, special relativity is arguably his least impressive work
Exactly. I mean, his Nobel prize wasn't even for relativity -- it was largely for his explanation of the photoelectric effect, which basically spawned quantum physics. He already had earned his Nobel before he even published E=mc^2.
Calling Einstein a one-trick pony is using an awfully liberal definition of "once".
This page says Caltech holds the copyright. Presumably they require(d) that faculty transfer copyright of works they did in the course of their employment to the university. My guess is that's probably standard provision for faculty, though I'm not positive.
rs1n and I both speculate that the reason they don't just release PDFs from the Latex source is that the publisher feels that would compromise physical book sales (and HTML doesn't).
Publish the Latex source and you're back to "publisher won't allow it" land (if our assumption holds).
Yeah, I had the same question.
My guess is that it's the "book sales would not be harmed" qualifier, with the assumption that just posting good PDFs would harm sales and an HTML version wouldn't.
I'm not sure how they got to that conclusion, but that's my guess anyway.
Sometimes, students don't like the teachers who force them to work hard and learn the material. That's why we have tenure.
Um no, it's not.
University faculty have tenure because donors to universities would sometimes force the university to fire faculty who took up controversial topics in the wrong direction.
...is this because they are inspired or is it because they make the material seem simpler (perhaps partly because they may be better teachers but also because they will not complicate matters by introducing their own cutting edge research)
Speaking as someone who just got his PhD and would like a teaching-focused faculty position in a few years, the study was looking at freshmen courses. I don't think it's a stretch to say that if you're wedging your cutting edge research into an intro class, you're almost certainly doing it wrong.
More likely is that I won't touch if it is unlicensed, because I don't know where I stand.
If it's unlicensed, it's very easy to know where you stand: nowhere, and legally speaking you have no permission to do anything with it.
(If it's on Github you have some token rights like the ability to look at the code and fork the repository -- whatever that means -- but probably don't have the right to, say, distribute it outside of Github. IANAL, YMMV.)
OK, so this is not actually quite right:
The answer: Our -96dB noise floor figure is effectively wrong; we're using an inappropriate definition of dynamic range. (6*bits)dB gives us the RMS noise of the entire broadband signal, but each hair cell in the ear is sensitive to only a narrow fraction of the total bandwidth. As each hair cell hears only a fraction of the total noise floor energy, the noise floor at that hair cell will be much lower than the broadband figure of -96dB.
Thus, 16 bit audio can go considerably deeper than 96dB. With use of shaped dither, which moves quantization noise energy into frequencies where it's harder to hear, the effective dynamic range of 16 bit audio reaches 120dB in practice... (source)
So there's rather more headroom (by about 20 dB) than I say.
However, even that link has this to say:
Professionals use 24 bit samples in recording and production [14] for headroom, noise floor, and convenience reasons.
16 bits is enough to span the real hearing range with room to spare. It does not span the entire possible signal range of audio equipment. The primary reason to use 24 bits when recording is to prevent mistakes; rather than being careful to center 16 bit recording-- risking clipping if you guess too high and adding noise if you guess too low-- 24 bits allows an operator to set an approximate level and not worry too much about it. Missing the optimal gain setting by a few bits has no consequences, and effects that dynamically compress the recorded range have a deep floor to work with.
An engineer also requires more than 16 bits during mixing and mastering. Modern work flows may involve literally thousands of effects and operations. The quantization noise and noise floor of a 16 bit sample may be undetectable during playback, but multiplying that noise by a few thousand times eventually becomes noticeable. 24 bits keeps the accumulated noise at a very low level. Once the music is ready to distribute, there's no reason to keep more than 16 bits.
so my overall point -- 16 bits is enough for the end user but not very good for mastering -- holds.
either you want the 1812 overture to be so quiet you can't hear most of it, or so loud it causes hearing damage, or you don't need more than 16 bits.
The thing is... 16 bits is enough, but only barely. A quiet room is about 30-40 dB above the threshold of hearing, and 16 bits gets you about 96 dB of signal-to-noise. I think it makes sense to add those numbers, and say that if you set the volume so you can just barely hear the quietest bits of a recording that covers the entire dynamic range, then the loudest parts will be at 126-136 dB. Coincidentally or not, that's actually right at the threshold of pain, which is typically quoted at 130 dB.
What this means is that there is little room for processing at 16 bits, or even making the recording in the first place (as you have to set the input volume so that you come close to clipping without actually clipping). Cut much more than 10 dB off the dynamic range and it'll be audible to careful listeners in realistic scenarios.
So the higher bit depth definitely makes sense for recording and mastering, just not so much for the end user. However, for a project like Musopen that is trying to make actual open recordings, it also makes sense to distribute the better recordings because they're the equivalent to source code. But like source code, most people don't get any (direct) benefit from it being available.
But yeah, the comment a couple parents up saying even 24 bits may not be enough: no. 24 bits is more than plenty.
Mod that up... it's a good explanation.
I'm convinced that 44.1/16 is beyond human hearing ability in realistic scenarios... but it's only a little beyond it. It leaves very little wiggle room for doing any processing.
Or even just recording. 16 bits actually records slightly less than the human ear can distinguish in really ideal conditions. Those conditions are pretty much "you're in a soundproofed room" with essentially no ambient noise, but that doesn't leave a lot of room to "a good listening environment". So if you're recording in 16 bits, now you've got to worry about setting the input volume almost perfectly, so that you've captured the quiet parts but never clip. Clip? That'll be audible in even mediocre conditions unless you make up stuff. Record volume 10 or 15 dB too low? Probably careful listeners in a good but realistic environment could tell. With 24 bits? Now you've got a ton of wiggle room.
More specific information: I picked out about 10 albums semi-arbitrarily (largely classical, but not entirely).
The total FLAC size is 4.11 GB.
The total WAV size is 7.93 GB.
So 48% decrease in size, which is even more than I said before.
If you are going to remix it then up mix it to 192kHz before you start hacking on it.
You'll never be able to pull audio out of recordings you downloaded from this project that doesn't exist
It's amazing you managed to write both of those sentences in the same post.
Dropping from 192 KHz to 44.1 destroys information that you can never get back. It's not information that can be used if you just listen to it, but it is information that can be used if you pass it through more editing stages.
Um, try a 30-45% decrease for the 5-10 tracks I tried. (Actually I had one that had around a 75% decrease, but it was an outlier.)
Is Jython an order of magnitude slower than CPython? Because that's my rule of thumb for CPython vs C. (Actually the programming language shootout's numbers are more like 30-40x slower than C, though that needn't be representative.)
Sure, but then that's not Python being fast, it's C++ being fast. "You could write the expensive parts in C or C++" can be said of nearly any language. :-)
CPython is... really quite slow. You [i]do[/i] have to do something computationally intensive to notice, of course.
That point and your parent's question are actually related to the PyPy question in the interview actually. PyPy is a JIT for Python that is able to get significant speedups for computationally-bound code. They run 20 benchmarks comparing PyPy and CPython, they are faster on all 20, and see speedups ranging from about a 27% improvement to a ~30x improvement, on average running 6.2 times faster. (Link)