The lowest power gasoline versions? Yeah, they're usually around 1600kg.
Shave about 300kg off and you'd be right.
Audi A4: 1295kg BMW 318i: 1300kg Mercedes: Well that one you quoted is 1600kg but at more than 100bhp more than the other cars you listed. The actual Mercedes with a low power gasoline engine is a C 180 which is 1350kg.
All three of those cars or the lowest power ones from their respective manufacturers too. You don't define luxury by "difficult to reverse parallel park"
I got to number 1 on the list and straight away you demonstrated to every marketing person that you are an odd case, not at all even remotely representative of their customer base and that your desires will be completely ignored going forward.
That's basically saying you're compromising a sieve's ability to hold water by drilling an additional hole in it.
There are very few quality product reviews left that don't go out and hand the product back to Apple all sticky while breathing heavily and saying "it was amazing". iFixit's reviews are good but those are limited to a specific aspect of the product.
Consumer reports... well they set their reputation on fire ages ago and poured gasoline over it this year just to make sure.
By far the most reviews of anything seem to focus almost entirely of what the review likes about a product, and providing the likes are high enough they gloss over the things that make a product frustrating to use.
Never happened to me and I use Outlook. I also have never heard of corruption being synced back to the server despite the fact that I have suffered from corrupted inboxes on many occasions.
Ahem, "ad-sense" is very much a monopoly by every definition of the term. Every other google service has not method of captivating the customer and fails on that part.
Because they didn't need to. If it were a recurring problem and the mac was able to demonstrate what you were trying to demonstrate then it wouldn't have been a problem either.
Yes they should, but the standard doesn't require it. If you read the datasheets of DIR chips they state that the only way to reach the required performance figures is to effectively implement input stage as AES3 specifies but with a different characteristic impedance. The problem is that costs money.
Phase locking an oscillator to the source doesn't actually reduce jitter, it just changes its frequency which still has a measurable effect on the analogue side (to be fair it is an improvement). A lot of high-end audio systems instead chose to implement asynchronous sample rate conversion locked to a new low jitter oscillator. Again the problem is that costs money (a good clock source costs as much as the main DAC ICs), and ASRC is also an imperfect process. This is the preferred option because most equipment these days upsamples anyway to make it easier to implement the analogue filter stage.
The way to fix it is to not incorporate the clock in the signal source. Unfortunately the effects of jitter were not understood when the standard was created. Some high-end audio actually bypasses all of this and gives you the option of running Inter-IC Sound (I2S) between equipment (usually with a short Ethernet cable). Problem is that really only works over very short distances (cm not meters) and it requires matching settings so really only works if you designed both pieces of equipment.
I also have seen one design transferring the clock signal to the source and then not attempting clock recovery at all at the DIR in the comfort of knowing the data will arrive at the right time anyway. Again non-standard.:-(
The Reds do that. They have the same power management settings too.
What I don't understand is why the marketing junk. Just list specifications. The fact that we're having the discussion in the form of questions that start with "don't they have" shows this method of not getting information across is a straight up marketing fail.
It seems you thought you were talking about a flawed format but you were really just talking about a flawed receiver...
A flaw specified as an allowed implementation in a standard is a flaw in the standard not a flaw in the receiver. The desire to produce products for the best possible price will invariably also lead to the flawed implementation being the preferentially adopted one.
Not sure about HDMI, but definitely it's the worst of any possible way to carry an S/PDIF signal.
Not that it matters, HDMI doesn't carry S/PDIF and is externally clocked anyway so jittering of the digital audio signal would have no effect on performance.
TOSLINK supports 24/192; I don't know where you heard otherwise.
TOSLINK was designed to transmit S/PDIF. S/PDIF was designed to support a maximum audio word length of 20bit and be functionally identical to to the AES/EBU standard. The 20bit limit was defined in IEC 60958. There are additional status bits on the end of the audio word which are used specifically in the AES/EBU standard which were re-purposed by some equipement to transmit 24bit audio over S/PDIF.
Quite critically: 24bit audio is not part of the standard. 24bit audio was not part of the standard when the TOSLINK system was developed. 24bit audio is POSSIBLE, but it's an absolute crapshoot when it comes to support on both signalling and hardware, in some cases working over all interfaces, in some cases only over the coax as they crappy optical garbage can't keep up cheap LED transmitters were know for this.
The fact that support for it is a crapshoot is very widely known.
If people still knew how to write HTML, almost no web site would need to use any "JavaScript" or other "active content", with all the security issues this implies.
Did you just join us from 1996? Do you even know how the modern internet works?
And in an effort to speed up their computers the browser windows were closed. Companies across the globe reported a large increase in productivity in their workforce.
Is there anyone left who doesn't realize that Cellphones at the hardware level are designed as surveillance and tracking devices?
Yes obviously. If these were designed as surveillance and tracking devices then we wouldn't need external and secret hardware that goes to great pains in order to track us.
I am beyond sick and tired of Slashdot trying to push the "Russians influenced the election!" BS that the left has been pushing. It's fake. It never happened.
I on the other hand look forward to reading these stories. Specifically the comments and heated thoughtless debates about them. Thankyou.
Err there is not nor ever will be a "getting rid of the analogue hole". The signals required to drive headphones or speakers are perfect for capturing and re-recording.
Plus this is digital.
Plus this is pointless. They are only phasing out the optical garbage. The signals are still available and converted to analogue elsewhere in the chain, and you're not going to see line level outputs disappear... ever. Not without ending the high end audio industry.
Yes there were a few like that, but read through the manuals. You'll find that you needed to use ADAT to support multi-channel audio. The "chip" you're talking about is nothing more than a digital receiver. If you dig into the products you'll find that various receivers support a multitude of different standards. But the fact remains that S/PDIF did not support multi channel audio and had some serious shortcomings (not the least of which was a 10m cable length) and thus was not used in professional equipment as anything other than an afterthought. AES3 was the professional interface.
which is why ADAT is using the same cables and transmitters, carries 8 channels, and is used everywhere...
Err ADAT did not use S/PDIF. The specific incompatibility with multi-channel audio was one of of the reasons it used neither S/PDIF nor the equivalent professional standard AES3. It was entirely proprietary to itself.
Oh okay, if you calculate making it through to the end of the rat race an achievement then sure let's go with that. Send me your email address so I can send you an auto-generated participation award.
Fucking tell me about it. All those people saying that they should just launch Chrome are ignoring the myriad of these systems now running on ARM architectures which lack a Chrome build.
Slashdot Mirror
The lowest power gasoline versions? Yeah, they're usually around 1600kg.
Shave about 300kg off and you'd be right.
Audi A4: 1295kg
BMW 318i: 1300kg
Mercedes: Well that one you quoted is 1600kg but at more than 100bhp more than the other cars you listed. The actual Mercedes with a low power gasoline engine is a C 180 which is 1350kg.
All three of those cars or the lowest power ones from their respective manufacturers too. You don't define luxury by "difficult to reverse parallel park"
Lead? We used to burn the stuff in our fuel. Forget the tiny bit in the car battery. We consume a shitload of the stuff.
I'm terrible at picking stocks. But I'd say buy now.
If that wasn't a suggestion to short then I don't know what is.
1) I have root access
I got to number 1 on the list and straight away you demonstrated to every marketing person that you are an odd case, not at all even remotely representative of their customer base and that your desires will be completely ignored going forward.
That's basically saying you're compromising a sieve's ability to hold water by drilling an additional hole in it.
There are very few quality product reviews left that don't go out and hand the product back to Apple all sticky while breathing heavily and saying "it was amazing". iFixit's reviews are good but those are limited to a specific aspect of the product.
Consumer reports... well they set their reputation on fire ages ago and poured gasoline over it this year just to make sure.
By far the most reviews of anything seem to focus almost entirely of what the review likes about a product, and providing the likes are high enough they gloss over the things that make a product frustrating to use.
Never happened to me and I use Outlook. I also have never heard of corruption being synced back to the server despite the fact that I have suffered from corrupted inboxes on many occasions.
Ahem, "ad-sense" is very much a monopoly by every definition of the term. Every other google service has not method of captivating the customer and fails on that part.
And notice how it worked but he didn't care? Just like all the Chrome users.
Because they didn't need to. If it were a recurring problem and the mac was able to demonstrate what you were trying to demonstrate then it wouldn't have been a problem either.
So not S/PDIF, and non standard. Why do you even bother posting?
Yes they should, but the standard doesn't require it. If you read the datasheets of DIR chips they state that the only way to reach the required performance figures is to effectively implement input stage as AES3 specifies but with a different characteristic impedance. The problem is that costs money.
Phase locking an oscillator to the source doesn't actually reduce jitter, it just changes its frequency which still has a measurable effect on the analogue side (to be fair it is an improvement). A lot of high-end audio systems instead chose to implement asynchronous sample rate conversion locked to a new low jitter oscillator. Again the problem is that costs money (a good clock source costs as much as the main DAC ICs), and ASRC is also an imperfect process. This is the preferred option because most equipment these days upsamples anyway to make it easier to implement the analogue filter stage.
The way to fix it is to not incorporate the clock in the signal source. Unfortunately the effects of jitter were not understood when the standard was created. Some high-end audio actually bypasses all of this and gives you the option of running Inter-IC Sound (I2S) between equipment (usually with a short Ethernet cable). Problem is that really only works over very short distances (cm not meters) and it requires matching settings so really only works if you designed both pieces of equipment.
I also have seen one design transferring the clock signal to the source and then not attempting clock recovery at all at the DIR in the comfort of knowing the data will arrive at the right time anyway. Again non-standard. :-(
Kind of my point:
RPM: Performance stat
Cache: Performance stat
designed for x per enclosure (marketing wank).
I blame Intel and AMD's marketing department for the errorsion of what used to be performance stats that we used to make our purchasing decision.
There's 4 points of difference, all available on their website.
Cool story. The fact you had to look it up IS the problem.
The Reds do that. They have the same power management settings too.
What I don't understand is why the marketing junk. Just list specifications. The fact that we're having the discussion in the form of questions that start with "don't they have" shows this method of not getting information across is a straight up marketing fail.
It seems you thought you were talking about a flawed format but you were really just talking about a flawed receiver...
A flaw specified as an allowed implementation in a standard is a flaw in the standard not a flaw in the receiver. The desire to produce products for the best possible price will invariably also lead to the flawed implementation being the preferentially adopted one.
To be clear: I am talking about a flawed format.
Not sure about HDMI, but definitely it's the worst of any possible way to carry an S/PDIF signal.
Not that it matters, HDMI doesn't carry S/PDIF and is externally clocked anyway so jittering of the digital audio signal would have no effect on performance.
TOSLINK supports 24/192; I don't know where you heard otherwise.
TOSLINK was designed to transmit S/PDIF. S/PDIF was designed to support a maximum audio word length of 20bit and be functionally identical to to the AES/EBU standard. The 20bit limit was defined in IEC 60958. There are additional status bits on the end of the audio word which are used specifically in the AES/EBU standard which were re-purposed by some equipement to transmit 24bit audio over S/PDIF.
Quite critically:
24bit audio is not part of the standard.
24bit audio was not part of the standard when the TOSLINK system was developed.
24bit audio is POSSIBLE, but it's an absolute crapshoot when it comes to support on both signalling and hardware, in some cases working over all interfaces, in some cases only over the coax as they crappy optical garbage can't keep up cheap LED transmitters were know for this.
The fact that support for it is a crapshoot is very widely known.
If people still knew how to write HTML, almost no web site would need to use any "JavaScript" or other "active content", with all the security issues this implies.
Did you just join us from 1996? Do you even know how the modern internet works?
And in an effort to speed up their computers the browser windows were closed. Companies across the globe reported a large increase in productivity in their workforce.
Is there anyone left who doesn't realize that Cellphones at the hardware level are designed as surveillance and tracking devices?
Yes obviously. If these were designed as surveillance and tracking devices then we wouldn't need external and secret hardware that goes to great pains in order to track us.
I am beyond sick and tired of Slashdot trying to push the "Russians influenced the election!" BS that the left has been pushing. It's fake. It never happened.
I on the other hand look forward to reading these stories. Specifically the comments and heated thoughtless debates about them. Thankyou.
Err there is not nor ever will be a "getting rid of the analogue hole". The signals required to drive headphones or speakers are perfect for capturing and re-recording.
Plus this is digital.
Plus this is pointless. They are only phasing out the optical garbage. The signals are still available and converted to analogue elsewhere in the chain, and you're not going to see line level outputs disappear ... ever. Not without ending the high end audio industry.
Yes there were a few like that, but read through the manuals. You'll find that you needed to use ADAT to support multi-channel audio. The "chip" you're talking about is nothing more than a digital receiver. If you dig into the products you'll find that various receivers support a multitude of different standards. But the fact remains that S/PDIF did not support multi channel audio and had some serious shortcomings (not the least of which was a 10m cable length) and thus was not used in professional equipment as anything other than an afterthought. AES3 was the professional interface.
which is why ADAT is using the same cables and transmitters, carries 8 channels, and is used everywhere...
Err ADAT did not use S/PDIF. The specific incompatibility with multi-channel audio was one of of the reasons it used neither S/PDIF nor the equivalent professional standard AES3. It was entirely proprietary to itself.
I call bullshit
I call ignorance.
Oh okay, if you calculate making it through to the end of the rat race an achievement then sure let's go with that. Send me your email address so I can send you an auto-generated participation award.
Fucking tell me about it. All those people saying that they should just launch Chrome are ignoring the myriad of these systems now running on ARM architectures which lack a Chrome build.