![]() |
thank you for your help, peaved.
you define 'noise' in the phrase 'signal-to-noise ratio'. |
According to Apple's website (although I have not tried it), iTunes 4 also allows you to encode your own AAC files.
Apparently, these files do not have any DRM restrictions... is this correct? |
Re: quality of iMS AAC tracks
Quote:
But in the context of this discussion, it should be pointed out that Apple claims that the AAC tracks are encoded from the studio masters. This means that it is possible - at least in principle - for the AAC tracks to be comparable in quality to audio CD tracks. |
hayne,
in terms of the iMS you're wrong here: no matter what the quality of the original input, the conversion process to AAC is by nature *lossy*, meaning you lose information in exchange for trimming size. but you are correct in a theorectical sense: if you were to compress to AAC at a very high data rate, say around 320kbps, the human ear wouldn't be able to tell the difference. apple is encoding at a much lower rate. they seems to be claiming 128AAC is equivelent to 160CBR MP3. if this is true, then the loss is likely to be noticeable to a reasonably perceptive ear. (FWIW, i believe apple is using 128kbps not only for the obvious bandwidth reasons, but also to make Fairplay more effective.) |
hayne,
Where does Apple make the claim that they are encoding from studio masters? |
petey,
why would 128kbps "make Fairplay more effective"? |
Compressed vs Uncompressed Formats
AAC & JPG are compressed formats. AIFF and TIFF and uncompressed formats.
the point where the human ear can no longer reliably differentiate between an AAC and a CD format AIFF is probably somewhere around 320kbps. the point where an AAC is acutally of equal quality (as much sound 'information') to a CD format AIFF would be at a much higher bitrate. the quality of an AIFF is determined by its bitrate and sample rate, both of which are fixed for CD's. working from a studio master, you could possibly produce an AAC file with an equal actual sound quality to a CD format AIFF. it depends on whether or not there are limits at the top end of the AAC specification. if AAC permits a bitrate and sample rate higher than CD format AIFF, then you could end up with an AAC that is better than CD quality. it's the same rationale that explains why you can have a JPG that of higher quality than a TIFF. |
petey,
you are way, way off about "the human ear". |
petey,
you haven't answered this question: why would 128kbps "make Fairplay more effective"? |
peaved,
128AAC is going to right around the border of Acceptable/Not Acceptable in terms of quality for most people. (for me it's slightly on the Not Acceptable side of the border, but that's besides the point.) transcoding something that borderline to MP3 (and thereby removing the Fairplay protection) should leave the quality of the MP3 at very low standards. probably around what you'd get encoding a CD to MP3 at 96kbps (i'm guessing, of course.) this will probably be unacceptable for many people. if apple had encoded at 192AAC, you could probably make decent MP3's out of that. and then you could send them around the net. maybe i'm being DRM paranoid here, and Apple's reasons for 128kbps is just bandwidth related, but i doubt it. PS why aren't you taking your Xanax like i told you to? |
petey,
thanks for the reply. strange little theory. anyway, are you going to apologize to hayne, now that you finally understand what he posted? |
Quote:
See, e.g. http://www.macnn.com/news/19276 |
From what I understand the AAC files you create by ripping a CD are OK, no *DRM* there.
The files from Apple have some kind of encrypted signature. The validation across computers, or deauthorisation is linked to that key. I suppose it's probably like GPG keys. Apparently, if you buy an AAC encoded song from *Apple Music* (ha!) and burn it AIFF style, then decide to re-rip the tune back to MP3 or AAC the quality would drop through the earth. So I suppose it doesn't matter which bitrate it's at if people want to *steal* the music. The problem comes in when your hard drive fails or if you have some problem and you have to reninstall your OS in a hurry. Extreme. Lets say you have *authorised* three (or just one it doesn't matter) computers and one decided to die on you. If you haven't deauthorised it then you're screwed. After you do what you need to do to correct any problem the music you've bought from your account can only be shared on two computers, or you could always buy it again. I think this is right. Somebody test it ;) *DRM* is just a fancy acronym for *you will buy my product and I don't trust you*. |
bassi,
i'm not sure that you wouldn't be able to deauthorize a computer that had exploded into a fine mist of silicone and arsenic. i bet the 3 keys are managed off the owner's appleID, and so the apple public key (?) could be changed at the request of the appleID owner, even without the physical existence of the non-existant computer. but i'm way out of my league here - request for info at the bottom of this post. if all i'm assuming is true, it should mean that apple could, in theory, allow you to redownload the files that went blooey on yr harddrive, for some token redownload fee to cover the bandwidth. the replacement file apple would let you download would give you no additional DRM abilities over the file you lost. ------------- can anyone give a short explantion of the mechanics of public/private keys in this context, and how they'd function around the troika of the AAC file, the authorized computer, and the AppleID login. the part that really confuses me is what goes down when a new machine gets autorized. - obviously, the AAC file doesn't change. - so does apple have to write some key onto the harddrive of the newly authorized machine? - if so, where and what is it writing on the machine. - and if that's right, if you lost or fried a machine, it would mean you'd lose one authorization. all that said, it doesn't seem like the most elegant solution, which is why i'm curious how the DRM mechanically works. it seems to me like there is some public/private key system where nothing has to written onto an authorized machine. any experts out there> |
Catastrophic hard drive failure is enough if the keys are not stored in nvram, if they do exist. I'm no expert on their DRM strategy, the key issue is a little foggy. Somebody will go through this someday and it'll be enlightening.
Here's some more info on the DRM stuff. edit: another article, links therein are informative. |
My thanks to the people trying to keep the thread on topic.
|
Quote:
On the other hand, it's my opinion that it is/was their methods and pricing policies--along with technology--that created this mess in the first place. |
my guess as to how it works
Here's my guess as to how it works.
(It can only be a guess since I'm in Canada and hence unable to experiment with it to check any theories.) I guess that when you authorize a computer to play a song, you connect to an Apple server and that server gives your computer a key (specially calculated numerical data) which gets stored on your hard disk somewhere. You are only allowed to have 3 such keys and somehow the key is tied to particular characteristics (serial number?) of your computer. And then when iTunes tries to play that song, it looks for the key. People with ability to purchase songs could test this theory by looking to see what files get changed by the purchase. |
Andrew, I like to compensate for products I use. I just like to do what I like with the product, within the bounds of the law. I agree with your opinion on RIAA tactics, they seem a little hamfisted.
Hayne, that's a good idea. There might be a file which holds the info in /library or ~/library. I wonder if it can be opened up by a editor? It'll probably spit back encrypted info of some sort. It has got to be the serial number for the identity along with your Apple ID, you can spool that just by getting info on your mac etc. The music server has to identify who you are uniquely, when you setup an account Apple groks your serial number and/or Apple ID and probably uses an algorithm to scramble that, the private key, then it continues to create a 'public' key from that. You keep a copy of this 'public key' in your database, synced with Apple's central server which has the key to decrypt your password and validate you. Deauthorisation just deletes your key and *might* invalidate your private key with Apple. You *might* want to reauthorise your computer again. Working offline allows you to continue with your music, theoretically. Actually sounds a bit flakely, illogical and overly complicated *must think harder*. Anyway I'm in the same boat, outside the US so I can't test the 'changed file theory'. |
thanks, hayne! (for the info about Steve Jobs' claims)
Personally, i think it's not feasible or very likely to happen for the vast majority of songs. There are lots of reasons why it will not happen. |
| All times are GMT -5. The time now is 12:20 PM. |
Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.
Site design © IDG Consumer & SMB; individuals retain copyright of their postings
but consent to the possible use of their material in other areas of IDG Consumer & SMB.