[SlimDevices: Audiophiles] Re: A sudden thought...
pfarrell Wrote: > Gentlemen, please. This is the audiophiles list. GPWM, time to call a halt to my ranting. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
My SqueezeBox is replacing a network-based music system of my own design. Until the SqueezeBox, I was listening to CDs playing from two Sony Jukeboxes controlled by a Slink-e, a serial device from a now-defunct company called Nirvis. The software that controls the Slink-e consisted of a proxy server, an ActiveX component and a VB6 ActiveX.exe that I wrote to wrap the OCX's properties and methods. The ActiveX.exe runs in IIS, and is controlled from a series of classic ASP pages that I also wrote. An Access database contains all of my album and track data. My observations comparing SlimServer to my own system First, I do not consider myself a world-class programmer. I know what Im doing, but there are much more talented folks out there than myself. Second, classic ASP and Access are regularly ridiculed for their speed of execution and scalability. Is spite of these facts, the speed and usability of the web interface of my own system is substantially superior to SlimServer at performing similar tasks (listing, sorting, etc.). My system's screen redraws are almost instantaneous. SlimServer's are a bit ponderous. Why is this? There is definitely something fundamentally slow either with Perl or the underpinnings of SlimServer. If you want to compare them yourself, e-mail me and Ill give you access to my intranet. jon[at]theheals[dot]org -- jonheal jonheal's Profile: http://forums.slimdevices.com/member.php?userid=2133 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On Fri, 2005-12-23 at 09:31 -0500, Jacob Potter wrote: > On 12/23/05, CardinalFang > <[EMAIL PROTECTED]> wrote: > > Perl does not encourage well written easy-to-maintain code. > The same applies to C, and it's pretty hard to argue that the use of C > leads to unsuccessful products. Gentlemen, please. This is the audiophiles list. I've been earning my living, which lets me buy music and stereos and squeezeboxen for over 30 years, in more languages than most people know even exist. You can write bad code in any language. All computer languages are weak implementations of the ideas of Alan Turing. If you want to debate languages to implement a SlimServer the developers list is the place, but most of them are too busy writing code to argue theology. Merry Christmas, and listen to music. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On 12/23/05, CardinalFang <[EMAIL PROTECTED]> wrote: > Perl does not encourage well written easy-to-maintain code. The fact > that there's an annual contest to write the most delibrately obfuscated > code tells me a lot. The same applies to C, and it's pretty hard to argue that the use of C leads to unsuccessful products. Perl has its problems, yes. But we're trying to /fix/ the memory and performance excesses of SlimServer, not make them worse. :) - Jacob ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Robin Bowes Wrote: > CardinalFang said the following on 23/12/2005 09:25: > >>>Java does allow you to wrap features up into nice, > >>>self contained functional blocks that can be black box tested and > >> > >>then > >> > >>>left well alone. That's my main gripe with Perl, it isn't a > language > >>>that enables that kind of unit construction of an app. > >> > >>Agian, not so. > >> > > > > Sorry, but Perl subroutines to me is a hack. > > Ah, to *you*, maybe. > Oh come on - no type checking, having to manage parameter lists yourself? Compare it to any other high level language like Java or C++, the code wouldn't even compile with errors in it that Perl would happily try to execute. And don't get me onto the half-hearted object orientation where you have to manage all the members yourself. The fact that it carries on executing in spite of minor errors makes it hard to track problems and along with no type or parameter checking wrecks any chance of black box testing. Perl does not encourage well written easy-to-maintain code. The fact that there's an annual contest to write the most delibrately obfuscated code tells me a lot. People contributing to SlimServer must struggle to work out each other's code and it's almost impossible to write robust, defensive code when the syntax is so Byzantine and hard to fathom. How often have you looked at Perl code, including the standard shipping components, and wondered what was going on in the code? I've looked at it and given up in most cases and I write code for a living. Life's too short. I meant what I said when I called it software Buckaroo. Perl is good at handling text and files, which makes it entirely suitable for web apps and build systems. Use tools appropriately, it's not a matter of preference, just common sense. > > > > Getting parameters using > > shift is horrible, it's like accessing a stack directly. Modules > aren't > > really encapsulation in my mind, they're a packaging feature. Java > class > > packages have much stricter checking on their usage when compiling > > apps. > > > > Perl is good because it is easy to get going with it, but it also > > allows you to be very undisciplined and lazy about coding style and > > legibility. Having to turn on "strict" to catch fundemental coding > > errors doesn't inspire confidence in me, I'm afraid. > > Again, that's personal. Just because *you* don't like it doesn't mean > it's a bad thing. > > > Looks like I disagree with most people on this forum again :-) > > It would appear so. > > R. Ok, here's a prediction then. If SlimServer continues to be written in Perl by a community without strict coding standards and proper unit testing and peer code review, then I predict that customer disatisfaction will increase and Apple will stomp all over the SlimDevices market with iTunes and iBox or whatever they call it. I'd hate to see that happen, but I see them coming along with increasing complaints about the SlimServer software as more and more gets added to it. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang said the following on 23/12/2005 09:25: >>>Java does allow you to wrap features up into nice, >>>self contained functional blocks that can be black box tested and >> >>then >> >>>left well alone. That's my main gripe with Perl, it isn't a language >>>that enables that kind of unit construction of an app. >> >>Agian, not so. >> > > Sorry, but Perl subroutines to me is a hack. Ah, to *you*, maybe. > Getting parameters using > shift is horrible, it's like accessing a stack directly. Modules aren't > really encapsulation in my mind, they're a packaging feature. Java class > packages have much stricter checking on their usage when compiling > apps. > > Perl is good because it is easy to get going with it, but it also > allows you to be very undisciplined and lazy about coding style and > legibility. Having to turn on "strict" to catch fundemental coding > errors doesn't inspire confidence in me, I'm afraid. Again, that's personal. Just because *you* don't like it doesn't mean it's a bad thing. > Looks like I disagree with most people on this forum again :-) It would appear so. R. ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
> > > > Java does allow you to wrap features up into nice, > > self contained functional blocks that can be black box tested and > then > > left well alone. That's my main gripe with Perl, it isn't a language > > that enables that kind of unit construction of an app. > > Agian, not so. > Sorry, but Perl subroutines to me is a hack. Getting parameters using shift is horrible, it's like accessing a stack directly. Modules aren't really encapsulation in my mind, they're a packaging feature. Java class packages have much stricter checking on their usage when compiling apps. Perl is good because it is easy to get going with it, but it also allows you to be very undisciplined and lazy about coding style and legibility. Having to turn on "strict" to catch fundemental coding errors doesn't inspire confidence in me, I'm afraid. Looks like I disagree with most people on this forum again :-) -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang said the following on 22/12/2005 12:00: > Perl doesn't really allow you to encapsulate the core stable parts from > further tinkering. That is incorrect. Read up on Perl modules. > Java does allow you to wrap features up into nice, > self contained functional blocks that can be black box tested and then > left well alone. That's my main gripe with Perl, it isn't a language > that enables that kind of unit construction of an app. Agian, not so. Slimserver isn't a particularly good example of such an application but that's an architectural issue rather than a "capability of the language" issue. Packages, modules, classes, etc. etc. are all features that enable "black box testing". If you mean you can't produce binaries to physically prevent people making any changes, then I'm not sure that is a desireable feature for an Open Source app. > In many ways, > SlimServer is an overgrown prototype. One which works, but I think is > creaking at the seams. Again, this is an architectural issue not a perl issue. > > Still, enough lambasting of other people's products, it's very easy to > be negative and have hindsight. There has clearly been a great deal of > vision in this product and I love it. Yes, it is a great product. It could be a lot better, but, as you say, hindsight is a wonderful thing. R. ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
mwphoto Wrote: > CardinalFang wrote: > > > Being able to easily change things isn't necessarily a good thing in > a > > mature product. > > > > That's where we disagree! :) While the product may be considered mature > in some sense (it is feature rich, stable, and relatively few bugs) I > believe it is a long way from the music server that people want. Well we agree on the music server aspect at least! I meant mature as in "been around for a while and generally working". Perl doesn't really allow you to encapsulate the core stable parts from further tinkering. Java does allow you to wrap features up into nice, self contained functional blocks that can be black box tested and then left well alone. That's my main gripe with Perl, it isn't a language that enables that kind of unit construction of an app. In many ways, SlimServer is an overgrown prototype. One which works, but I think is creaking at the seams. Still, enough lambasting of other people's products, it's very easy to be negative and have hindsight. There has clearly been a great deal of vision in this product and I love it. Paul -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
RE: [SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang wrote: > Being able to easily change things isn't necessarily a good thing in a > mature product. > That's where we disagree! :) While the product may be considered mature in some sense (it is feature rich, stable, and relatively few bugs) I believe it is a long way from the music server that people want. I think the market is just working out what can be done with these things and there's a long way to go before it becomes apparent what the market wants in terms of features. I'm not criticising, I don't have a vision for what it should be, I just believe that a lot will change in the coming years as more consumers get exposed to the concept of music servers. For that reason I think development flexibility and open development are the most critical features to keep in any long term strategy. Of course that doesn't preclude it being redeveloped in java, C#, c++, or cobol. But from my point of view perl rates higher than the others on development flexibility and so I'd like to retain it, especially for the server management code. However the piece that I do believe is mature is the core 'music streaming' server and I can see some arguments for stripping it out from the code that manages the collection and playlists. Anyway, just my point of view. Malcolm ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
mwphoto Wrote: > One other significant advantage from the current perl implementation is > that it is relatively easy to make changes and there is an established > community building new features. Being able to easily change things isn't necessarily a good thing in a mature product. Don't get me wrong, I like the product otherwise I wouldn't have bought it, but I think a new generation of server is required. All software has a lifespan, it's not a comment on the quality of the old code base, just recognition that requirements, operating environment and markets change and sometimes the original design concepts become an impediment to necessary changes. Sure 6.5 may add threads, but how much effort is being expended on that? How stable is the code base afterwards? I'm guessing that we'll have quite a few months of instability. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cbemoore Wrote: > Do you realise that 2 of the biggest things being developed for the > Slimserver 6.5 release are faster scanning and multithreading?? Yes I did, but all that means is that the original design didn't anticipate large database performance and that it is being fixed now. If a more appropriate language had been chosen from day 1, threads would have been there from the start. Legacy code isn't a reason to not change course to do things right. Don't get me wrong, the community aspect of this is fantastic, but we really aren;t using the right tools and to a large extent hampering progress. IMHO of course. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
RE: [SlimDevices: Audiophiles] Re: A sudden thought...
One other significant advantage from the current perl implementation is that it is relatively easy to make changes and there is an established community building new features. While this is also possible with open source in any language I believe it would take a long time to rebuild the community. One of the big 'features' of slimserver is that it is the development is highly responsive to what the market wants, because the market develop and contribute it. I haven't seen any other open source project with as much real development shared in a wide community (except possibly firefox, but I don't actively participate in that community to know) Malcolm ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > Because SlimServer is flawed as it stands in not being multi-threaded > and being very, very slow at times. Java has some good features for > supporting threads and runs very fast on modern VMs. The SlimServer > library scan times alone are enough to make me switch to another > product today. Do you realise that 2 of the biggest things being developed for the Slimserver 6.5 release are faster scanning and multithreading?? Personally, I don't care whether Slimserver uses Perl, Java or something else. Its the end result I care about. Currently I agree that scanning is very slow and sometimes causes audio dropouts, but I'm confident that this will be fixed in the 6.5 release. Chris -- cbemoore cbemoore's Profile: http://forums.slimdevices.com/member.php?userid=163 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Jacob Potter Wrote: > I don't see how "Java front-end app plus from-scratch rewrite of > SlimServer" is supposed to be better than "Java front-end app plus > proven, tested, feature-complete SlimServer". Because SlimServer is flawed as it stands in not being multi-threaded and being very, very slow at times. Java has some good features for supporting threads and runs very fast on modern VMs. The SlimServer library scan times alone are enough to make me switch to another product today. You also have to examine whether this is the right foundation for the server over the next few years as competition hots up. I don't think it is, based on my software development experience, but everyone is free to disagree. My company uses Perl and Java and in my experience Perl is good for building software applications, not being the software application. All my opinion only, of course, but it is based on using all the aformentioned technologies and feedback from developers on their strengths and weaknesses. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
ezkcdude wrote: Have any of you seen the Java clone of iTunes? http://sourceforge.net/projects/jtunes4/. It's being hosted on sourceforge. looks like the project hasn't seen much action since the middle of 2004. ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Have any of you seen the Java clone of iTunes? http://sourceforge.net/projects/jtunes4/. It's being hosted on sourceforge. -- ezkcdude ezkcdude's Profile: http://forums.slimdevices.com/member.php?userid=2545 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On 12/20/05, CardinalFang <[EMAIL PROTECTED]> wrote: > It was fine in the early days when all that was needed was a enhanced > scripting solution to push files around, but to remain commercially > competitive, SlimServer needs to look as good as and be as > ergonomically efficient as an Apple product. You can question how right > Apple have got it, but so many people use iTunes and that's what they > now expect from a digital music software product. > > I guess you could write a Java front end app to drive SlimServer, but > we're back to software Buckaroo. There are better ways to do it. I don't see how "Java front-end app plus from-scratch rewrite of SlimServer" is supposed to be better than "Java front-end app plus proven, tested, feature-complete SlimServer". This isn't a question of Java vs. Perl, it's a question of native control application vs. browser-based interface. The scope of SlimServer dicates a separate front end and back end; a Java-based front end does not necessitate a Java server. ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Jacob Potter Wrote: > As far as I know, a PC-based UI isn't even in the scope of that > project. There's no reason why someone couldn't write a richer > front-end for the current server (in whatever language) without > throwing away everything that SlimServer already does. > - Jacob Perhaps not in the current phase of that project, but it is going open source and it's a damn site easier to do it in Java than Perl! The problem with the curent server is the lack of multi-threading, poor debugging/GUI development tools and to be frank the inappropriate use of Perl for what has become - or needs to become - a rival for iTunes. It was fine in the early days when all that was needed was a enhanced scripting solution to push files around, but to remain commercially competitive, SlimServer needs to look as good as and be as ergonomically efficient as an Apple product. You can question how right Apple have got it, but so many people use iTunes and that's what they now expect from a digital music software product. I guess you could write a Java front end app to drive SlimServer, but we're back to software Buckaroo. There are better ways to do it. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Jacob Potter Wrote: > > As far as I know, a PC-based UI isn't even in the scope of that > project. There's no reason why someone couldn't write a richer > front-end for the current server (in whatever language) without > throwing away everything that SlimServer already does. > - Jacob What project is this? Does anyone have a link to it? Thanks, Jon -- jhwilliams jhwilliams's Profile: http://forums.slimdevices.com/member.php?userid=1876 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On 12/18/05, CardinalFang <[EMAIL PROTECTED]> wrote: > I am encouraged by the Java server project that someone has started - > on a PC with a modern VM it should run nearly as fast as native code > and look good too. If that comes to fruition soon, then I think we have > a fighting chance. As far as I know, a PC-based UI isn't even in the scope of that project. There's no reason why someone couldn't write a richer front-end for the current server (in whatever language) without throwing away everything that SlimServer already does. - Jacob ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Mike Anderson Wrote: > On the other hand, if Slim Devices comes up with a really nice GUI for > the Squeezebox, I'm married to it for good. That's the really key thing, SlimServer looks OK, but it is so painfully slow to use and the web interface makes it really hard to give good feedback to the user on what's going on. It's dependant on whole screen refreshes just to update fields and knowing the status of any operation is nigh on impossible. iTunes beats it fair and square for me I'm afraid. I am encouraged by the Java server project that someone has started - on a PC with a modern VM it should run nearly as fast as native code and look good too. If that comes to fruition soon, then I think we have a fighting chance. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
dwc Wrote: > I'd never go Apple. I prefer freedom. > -Dan Many people will though for the ease of use and strong integration - iPod has trounced all comers in its market. I like the audiophile and hackability side of SB and I don't think Apple will go that way myself, but I do think they may sweep up the mass market for networked players amongst iPod users at least. Roku are probably in the worst position, they don't have an end-to-end solution to fight back with. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
I'd never go Apple. I prefer freedom. -Dan -- dwc dwc's Profile: http://forums.slimdevices.com/member.php?userid=1892 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Unless Apple makes something that can deal with FLAC (and so far they haven't), I won't be buying it. If it does FLAC, sounds as good as the Squeezebox, and uses the iTunes frontend, I'll have to think about it very hard. On the other hand, if Slim Devices comes up with a really nice GUI for the Squeezebox, I'm married to it for good. -- Mike Anderson 'FREE RADICAL RADIO!' (http://nvo.com/cd) Hours of free radical MP3s. Mike Anderson's Profile: http://forums.slimdevices.com/member.php?userid=1705 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > Now you've really spoiled my day. The prospect of the Apple steamroller > squashing the likes of Slim Devices (like they did to Rio) is just too > depressing to contemplate. I actually edited this bit out of my response as I thought it might be the wrong place to put it, but yes, Apple have a whole iPod division and they are working on a SB-type device, amongst other things, to marry up with iTunes. It really does expose the weak spot in the the product, SlimServer. It will also presumably stream video and podcasts. The XBox360 has WiFi and can stream from a PC, so there are more of these well-integrated devices coming along into people's living rooms, and it's people who really aren't audiophile's. My personal view is that Slim need to go more audiophile with a higher end device, but I can also see why they would want a slice of the mass market. Unfortunately the iPod brand name will wipe out any company with less than millions to spend on marketing like they did with Rio. Would I change sides? If the "iBox" sounds as good as SB and have a digital output, it'll be a tough decision. I find SlimServer intensly frustrating. I am a coder, if a slightly out-of-practice one, so why don't I fix it? Well I think it has become the software equivalent of "Buckaroo". It has outgrown it's original foundations and each feature we add makes it teeter more and more. I really think it needs to be re-engineered in Java, but that's a major re-think of the SB strategy and it isn't my company. (quick edit - A message I posted a few days ago) http://www.appleinsider.com/article.php?id=1412 Rumours are that they have a Roku-like boombox and other devices ready to be revealed in January. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Patrick Dixon Wrote: > Surely in base 4, 2+2 = 10? err yes. Oops. Serves me right for typing answers late at night and not re-reading them. My point was really that what we are discussing is defined behaviours, not "facts". -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
> Actually, 2+2=0 in base 4 (for all you 4-bit ALU computing fans > from the 1970's). 2+2=4 only under very specific conditions.Surely in base 4, > 2+2 = 10? -- Patrick Dixon www.at-tunes.co.uk Patrick Dixon's Profile: http://forums.slimdevices.com/member.php?userid=90 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > I don't think I clained it did suddenly acquire extra data from thin > air. OK, sorry, I obviously misinterpreted this statement you made: > Where I get my reasoning from is derived when you browse CDs in windows > explorer where the audio is presented as data tracks and therefore > presumably subject to yellow book methods for data retrieval. > All I have supposed all along is that because a yellow book drive is > under computer control it can attempt to read the Red Book data in > different ways, for example by varying spin speed and repeated attempts > to read the red book data. And I'm not talking about deliberately > corrupted disks, just worn and less than perfect new ones. I have always agreed that ripping using a computer drive is the best way of getting the data off a damaged disc. You won't find me disputing this in any of my previous postings in this thread. And you'll also find that I do agree that hard disk based playback is the future. I do not have a vested interest in the continued existence of CD players. All I ever wanted to do was point out a flaw in your speculation, because it detracts from the basic truth that hard disk based replay *is* superior. > When I have discussed random ideas with bright people before on groups > like this, they usually respond with "no, that doesn't work, but this > might". But what you suggested *does* work. It's just that the reason why its a good idea isn't the main one you gave. > I also believe that unless we collectively make this the best, most > reliable audiophile solution for ourselves, it will be eclipsed by > Apple and others with their variations on networked players. Make no > mistake, they are coming - I believe strongly that by next summer there > will be a "iBox". Now you've really spoiled my day. The prospect of the Apple steamroller squashing the likes of Slim Devices (like they did to Rio) is just too depressing to contemplate. -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > Disagreement over opinions is one thing, disagreement over facts is > another. If I were to disagree that 2+2=4, I'd be wrong. Actually, 2+2=0 in base 4, for all you 4-bit ALU computing fans from the 1970's Come at things from a different angle and "facts" can be subtly changed. CDs are Red Book, yes, computer drives are Yellow book, yes. How they can and do interact isn't fully defined as each drive can implement different firmware and use different approaches to physically reading disks even if the definition of the data is the same. > When you put an audio CD into a data drive, it doesn't suddenly acquire > an extra level of error correction capability: the redundant data > simply doesn't exist, and information cannot be invented out of thin > air. Red book CDs cannot be read as yellow book ones. I don't think I clained it did suddenly acquire extra data from thin air. All I have supposed all along is that because a yellow book drive is under computer control it can attempt to read the Red Book data in different ways, for example by varying spin speed and repeated attempts to read the red book data. And I'm not talking about deliberately corrupted disks, just worn and less than perfect new ones. I am merely thinking out loud and very much wishing that I hadn't started. When I have discussed random ideas with bright people before on groups like this, they usually respond with "no, that doesn't work, but this might". I was hoping for the same so that we could collectively come up with some genuine ideas for a better SB/ripping experience. I am genuinely sorry if I have inflamed people by not giving up on trying to find out if we are limited by the technology we have to hand. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > > As it happens, I'd never tried copying a track from an audio CD using > Explorer, so I've just done it: dragged "Track01.cda" from the CD drive > to the hard disk. What I ended up with was a 44 byte file containing a > RIFF header and no audio data at all. This was using Windows 2000. Can > anyone tell us what happens under XP? Just the same on XP. Were it otherwise, there would be no need for all those ripping programs out there... Ceejay -- ceejay ceejay's Profile: http://forums.slimdevices.com/member.php?userid=148 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > Well you also need to accept that I because I don't agree doesn't make > me wrong. I grasp all your points, I just don't agree with all of them. Disagreement over opinions is one thing, disagreement over facts is another. If I were to disagree that 2+2=4, I'd be wrong. > Where I get my reasoning from is derived when you browse CDs in windows > explorer where the audio is presented as data tracks and therefore > presumably subject to yellow book methods for data retrieval. When you stick an audio CD into Windows and Explorer shows you a bunch of CDA files, it's simply giving you a view of what's on the CD that better fits the Explorer interface model. Those files don't actually exist. A red book CD (audio format) has two levels of error correction codes. A yellow book (data format) CD has three levels. When you put an audio CD into a data drive, it doesn't suddenly acquire an extra level of error correction capability: the redundant data simply doesn't exist, and information cannot be invented out of thin air. Red book CDs cannot be read as yellow book ones. > In other words, what exactly happens when you open a audio track as a > data file that has errors in Explorer and try to copy it? What type of > error correction is used? I assume no concealment is done since it now > treats it as data, not audio. If there are uncorrectable errors on the audio CD, then whether they are concealed when you access it through Explorer will depend on the firmware of the CDROM drive: some drives implement concealment, and some don't. As it happens, I'd never tried copying a track from an audio CD using Explorer, so I've just done it: dragged "Track01.cda" from the CD drive to the hard disk. What I ended up with was a 44 byte file containing a RIFF header and no audio data at all. This was using Windows 2000. Can anyone tell us what happens under XP? -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
teanau Wrote: > thats a great call mr fang. > especially if it could be done quietly in the background over night. > > i imagine the same set up is fraught with the potentual to corrupt alot > of perfectly good cds too if tampered with. > > a legal mine field too. > but could alleviate alot of audio health hypocondria... > > _sam All true, but if it only worked if you registered your CD and so proved had a legitimate rip, it could work quite nicely. It would be a legitimate way for you to copy your CD to a new master or keep it as a data file for the SB. Instead of having to download megabytes of lossless audio data, all you had to do was buy the CD and then compare track checksums with an online master via an application like EAC. If they were different, you would download the data to fix any manufacturing errors in your copy, run a fix-up program and then burn it back to CD-ROM for a high quality home master. If you already own the CDs and had ripped them and want studio quality masters to replace the damaged versions, then an overnight fixup would be great. It would need record company buy-in, but audiophiles would go for it I'm sure - upgrade all your CDs/rips to master quality. It would howvere be superb as an open source project and so get people adding in their CD data so that together we had a fix database for our CDs to get them all up to the best possible quality. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
thats a great call mr fang. especially if it could be done quietly in the background over night. i imagine the same set up is fraught with the potentual to corrupt alot of perfectly good cds too if tampered with. a legal mine field too. but could alleviate alot of audio health hypocondria... _sam -- teanau teanau's Profile: http://forums.slimdevices.com/member.php?userid=2575 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > I will admit to becoming increasingly exasperated that you seem unable > to grasp the points I've been trying to explain, and this is the reason > for the gradual decrease in politeness. I'm not trying to make you look > stupid - I'm trying to explain something, but do acknowledge that my > patience is getting a little thin. I'll try to be a little more civil > in future. Well you also need to accept that I because I don't agree doesn't make me wrong. I grasp all your points, I just don't agree with all of them. The basis of you argument seems to be that because a CD is red book, that it can only be read as red book, please correct me if I'm wrong. If that was the case then you would not be able to browse CDs in windows explorer for example where the audio is presented as data tracks and therefore presumably subject to yellow book methods for data retrieval, hence my supposition that yellow book error correction *could* be applied and you may not need to conceal the holes. Several DRM mechanisms rely on the fact that computer drives use yellow book to read CD disks and put spurious yellow book data there to screw up a rip by making the PC think it's a data disc, not an audio disc. I entirely agree that a perfect CD ought to play the same on both drives, and one with missing data will sound bad, my feeling is still that a good rip is better than most cd players manage when playing back discs since most discs do have scratches and manufacturing faults. To explain my stance better - I'm the CTO of a software company and the way I learn is by challenging assumptions and perceived wisdoms. If there is irrefutable evidence that something is one way, then I won't argue, but where there are greyish areas, I won't close my mind to the possibilities. Often new products and ideas can be found in the places where people say things can't be done. I'm actually very interested to understand if there is a new type of product in here - an connected communal CD player, if you will, than can scan a CD, find errors and correct them from online data from a database of correct CD data. No plans to produce such a product, but an open source database of extended error concealment data to produce a data set that could be used to play the CD perfectly, hence avoiding DRM/copyright issues. i.e it never rips the CD, just uses online extended iformation to fix errors rather than trying to conceal them. Of course it would work better at an adjunct to SB to compare and corerct rips, but then we're back in copyright problems. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > please be less aggressive over what is meant to be a friendly > discussion. I was trying to debate the pros and cons of different > methods of audio playback and you're trying to make me look stupid - I > assure you I have a brain between my ears. I'm sorry if I seem aggressive. If you re-read the postings I've made in this thread, you'll see that I started out with a simple correction of what I perceived as a misunderstanding on your part, in what I felt was a neutral and non-aggressive manner. I will admit to becoming increasingly exasperated that you seem unable to grasp the points I've been trying to explain, and this is the reason for the gradual decrease in politeness. I'm not trying to make you look stupid - I'm trying to explain something, but do acknowledge that my patience is getting a little thin. I'll try to be a little more civil in future. > My position didn't change, I believe a careful rip using a high quality > drive is better than most CD players achieve when playing back the same > CD for the reasons I stated - a CD player has limited time and computing > power to restore damaged data. This is certainly true, but only for genuinely damaged audio CDs with (non-intentional) uncorrectable errors. In those cases you have a better chance of retrieving a clean sample stream from it with a tool like EAC, Plextools, etc. However, I still get the feeling that you are labouring under the mistaken impression that a data drive is able to do "better" error correction than a CD player. Let's recap: if a CD is undamaged and contains only C1 errors below the maximum allowed BLER (220/sec), then an audio CD player will perform *perfect* error correction. Any that fails to do so is malfunctioning. I've never denied that ripping CDs to a hard disk is a superior method of music delivery. All I ever did was point out one small error in your original speculation. It was a friendly correction, but it escalated from there because you refused to accept it. > Try to lighten up, it's only a discussion board, and try to accept that > the way we learn is by asking questions and debating things we're not > sure about. I'm really a pussycat, you know :-) EDIT: Hey, since when did I become a "Senior Member"? I'm not *that* old, you know! -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
'This article' (http://www.positive-feedback.com/Issue22/nugent.htm) by Mr. Empirical Audio gives some answers to several questions regarding this issue. -- vdorta DIY computer (EAC, AccurateRip, FLAC) --> wireless SB2 (Bolder digital & analog mods, Sonicap Platinum bypass caps, Bolder Deluxe Power Supply) --> Stello M200 monos --> ACI Sapphire XL on dedicated Sound Anchors + REL Storm III | JMT PPA headamp with bass boost --> AKG K501, Etymotics ER-4S vdorta's Profile: http://forums.slimdevices.com/member.php?userid=1446 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > Do you actually understand the difference between error correction > (which happens *continuously* while reading even a pristine CD) and > error concealment (which happens very rarely - in fact usually not at > all on an undamaged CD)? I admit that CD audio is not my expert field, but there is no reason for the condescending and pompous tone you take to what was originally a playful discussion on the advantages of the SB over a CD player. I'm ready to be wrong, but not insulted. My position didn't change, I believe a careful rip is better than most CD players achieve when playing back the same CD for the reasons I stated - a CD player has limited time and computing power to restore damaged data. Try to lighten up, it's only a discussion board. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > Data drives also have more capabilities than audio only drives. Not when they're reading audio CDs, they don't. > Offline rather than real-time allows you to spend more time and > processing power to make corrections or gather the correct data. No. On a "copy-protected" CD that has deliberate uncorrectable errors, THERE IS NO CORRECT DATA TO BE RETRIEVED. All any CD reader can do (whether it's an audio player or a data drive) is to conceal the error using interpolation. And there is no systematic evidence to suggest that data drives do better interpolation than audio players. I happen to have compared the interpolation performed by my Plextor PX712A versus that done by a Micro-Seiki CD-M100 (which uses a Philips CDM1 mechanism), and can report that the Plextor's interpolation was slightly better than the Micro-Seiki's, but that's just one data point and has no statistical significance. > For example, tools like IsoBuster can often recover audio data that a CD > player can't by applying many different types of error correction or > data retrieval since they use Yellow Book not Red Book only like a CD > player. An audio CD is Red Book. It can't be read as a Yellow Book disc, because it simply does not include the additional level of redundant error correction codes. Rippers that can retrieve data from a damaged disc that an audio player can't play do so by repeated re-reading of the bad blocks until they get something usable. But a CD with deliberate uncorrectable errors cannot be successfully ripped like this - no matter how many times you re-read, you'll get exactly the same uncorrectable errors. If Isobuster (which I've not used) has especially sophisticated error concealment algorithms, then I applaud it. But it can only ever start with the raw data it's got to work with, and that is no different than what an audio CD player can do. And in any case, has your position suddenly changed from a belief that hard disk playback is better in all cases (as was implied by your first post in this thread) to one of thinking that it's only better on deliberately corrupted discs? As it happens, my position is that a hard disk setup is certainly better than a CD player in the case of damaged (but not deliberately corrupted) discs, because it is these cases where non-realtime ripping has a realistic chance of beating a CD player. (And there's another reason why it's more reliable, which you mention later on) > I was absolutely correct that CD players need to use error correction a > lot more than occasionally on many new discs Do you actually understand the difference between error correction (which happens *continuously* while reading even a pristine CD) and error concealment (which happens very rarely - in fact usually not at all on an undamaged CD)? > Additionally CDs gradually degrade from scratches and oxidation, data on > a hard disk does not slowly change and can be protected using RAID. > Doing an up-front rip on a brand new disc using data retrieval tools > like EAC on good discs and IsoBuster on badly corrupted discs will > result in a consistent audio signal over time, the CD in the CD player > will not. You've finally given one good reason why using a hard disk based system is probably more reliable than CD players, and I agree with you on this point. -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > Those CDs include deliberate uncorrectable errors, and rely on the CD > player's interpolation algorithms to conceal them. So how do you plan > on copying them to your hard disk? Data drives also have more capabilities than audio only drives. Offline rather than real-time allows you to spend more time and processing power to make corrections or gather the correct data. For example, tools like IsoBuster can often recover audio data that a CD player can't by applying many different types of error correction or data retrieval. They are not misunderstandings, they are an educated point of view based on available information and my experience of electronics and software. My supposed misunderstanding about CD players needing to use error correction more often than you would say is entirely correct for many new discs - Philips back this up by asking for discs with these errors to remove CD logo. CD Drives in PC and ripping software use different methods to extract the audio data than a CD player, Red Book or not. CDs degrade from scratches and oxidation. An up-front rip when new will stand the test of time. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
Thanks very much for the list of corrupt CDs. It made very interesting reading. I found a couple of disks on there that EAC was struggling with when extracting using my LG DVD Rom (Beatles, Let it be Naked and Pink, Try this). However I did find that my NEC DVD Writer combined with EAC managed to get a clean read. One odd thing to note was that the error buffer would fill one line and then clear every few seconds (a very regular pattern). This was presumably the injected junk being sorted out by EAC's error correction. Suffice to say that the final rips of these albums sound fineBUT error correction is never going to be the same as raw data. In the end I have rips that at least sound as good as my CD Player could manage. I'm starting to feel short changed though. -- Browny Browny's Profile: http://forums.slimdevices.com/member.php?userid=2295 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > OK, can I point you at this web site that lists all the CDs with > deliberately error-laden data to try to fool computer CD drives. It is > not an incorrect assumption that CDs are not manufactured error-free > anymore but a well-documented one with several sites reporting > deliberately corrupted CDs, usually by missing out information such as > time-stamps. In the old days CDs were produced to a high quality and > you'd be right, but not now. Those CDs include deliberate uncorrectable errors, and rely on the CD player's interpolation algorithms to conceal them. So how do you plan on copying them to your hard disk? These errors aren't random, and it doesn't matter how many times you get EAC to re-read them, they'll never go away. So you have to rip using a drive (or perhaps software) which includes interpolation of uncorrectable errors - just like a CD player. Once on hard disk, you can then faithfully play a data stream complete with the error concealments - just like a CD player. Hey, I'm not here to defend the idea of a CD player in preference to a Squeezebox - in fact I sold my CD player after getting an SB2. But some of your speculations about why a CD player may be an inferior transport to an SB appear to be based on misunderstandings, and I felt they should be clarified. -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
cliveb Wrote: > Your argument seems to be based on the assumption that CDs are rarely > read correctly, and error concealment is required most of the time. > This assumption is incorrect. OK, can I point you at this web site that lists all the CDs with deliberately error-laden data to try to fool computer CD drives. It is not an incorrect assumption but a well-documented one with several sites reporting deliberately corrupted CDs, usually by missing out informatrion such as time-stamps. http://ukcdr.org/issues/cd/bad/#uk I have had to return discs that won't play in my car because of these types of copy protection. Zero 7 was the last one. Furthermore I wasn't suggesting in any way that error correction was happening all of the time, just some of the time. It's also in the New Scientist: http://www.newscientist.com/article.ns?id=dn998 It's going to get worse, audio quality will be degraded in order to stop discs being read in computer drives. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On Mon, 2005-12-12 at 02:43 -0800, cliveb wrote: > CardinalFang Wrote: > > I read in the article that since the sound data is extracted via > > computer onto hard disk and because computers need bit-perfect data, we > > are getting a more acccurate experience than a CD player that > > error-corrects and filters data on-the-fly. > Your argument seems to be based on the assumption that CDs are rarely > read correctly, and error concealment is required most of the time. > This assumption is incorrect. The audio CD format is surprisingly > robust. Undamaged CDs played on correctly functioning audio players > deliver a 100% perfect data stream in the vast majority of cases. The > error correction that CDs players constantly apply is just that: error > *correction*. (By the way, hard disks also rely on error correction). It is true that undamaged CDs deliver all of the data in huge majorities of the time. The error correction logic is quite good. The RedBook specs also include specs for what to do when the errors can not be corrected. It happens, somewhere between rarely and extremely rarely. When it happens, the player fakes it. For non-critical listening, you are unlikely to notice it. EAC and other PC programs use a different approach to reading, but the result is essentially the same. And they are highly sucessful. I don't know what EAC does when it just can't extract a block from the CD. I've never had it happen. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
CardinalFang Wrote: > I read in the article that since the sound data is extracted via > computer onto hard disk and because computers need bit-perfect data, we > are getting a more acccurate experience than a CD player that > error-corrects and filters data on-the-fly. Your argument seems to be based on the assumption that CDs are rarely read correctly, and error concealment is required most of the time. This assumption is incorrect. The audio CD format is surprisingly robust. Undamaged CDs played on correctly functioning audio players deliver a 100% perfect data stream in the vast majority of cases. The error correction that CDs players constantly apply is just that: error *correction*. (By the way, hard disks also rely on error correction). -- cliveb cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
bludragon Wrote: > I think that's pretty optimistic, unless living in the US means you have > to suffer some really bad 'audiophile' equipment, or you're comparing it > to something designed well over 5 years old. > > That whole part of the article seemed more like hearsay to me. Yes, > squeezebox is good, yes it makes a good transport, but a modern $300 cd > player uses a fixed crystal clock too. A pc may do a better job with a > marginal/damaged cd, but otherwise the difference shouldn't be > significant. The point to me was that the SB eliminates the mechanical transports completely - there is no CD mechanism, so the cost comparison isn't strictly fair either. -- CardinalFang CardinalFang's Profile: http://forums.slimdevices.com/member.php?userid=962 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
Re: [SlimDevices: Audiophiles] Re: A sudden thought...
On Sat, 2005-12-10 at 16:28 -0800, bludragon wrote: > pfarrell Wrote: > > So you should expect it to sound as good as > > a $1000 or more 'audiophile' CD player. > I think that's pretty optimistic, unless living in the US means you > have to suffer some really bad 'audiophile' equipment, or you're > comparing it to something designed well over 5 years old. More a comment on my lack of confidence in the whole concept of audiophile CD players. All of the transports on things less than insanely priced, are PC parts. The internal DACs are all from the usual players. I can almost understand audiophile turntables and carts, but CDs are commodities. Then again, I never understood $500 interconnects. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
[SlimDevices: Audiophiles] Re: A sudden thought...
pfarrell Wrote: > On Sat, 2005-12-10 at 13:02 -0800, CardinalFang wrote:[color=blue] > So you should expect it to sound as good as > a $1000 or more 'audiophile' CD player. > I think that's pretty optimistic, unless living in the US means you have to suffer some really bad 'audiophile' equipment, or you're comparing it to something designed well over 5 years old. That whole part of the article seemed more like hearsay to me. Yes, squeezebox is good, yes it makes a good transport, but a modern $300 cd player uses a fixed crystal clock too. A pc may do a better job with a marginal/damaged cd, but otherwise the difference shouldn't be significant. -- bludragon bludragon's Profile: http://forums.slimdevices.com/member.php?userid=1530 View this thread: http://forums.slimdevices.com/showthread.php?t=18991 ___ audiophiles mailing list audiophiles@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/audiophiles
