Buying MP3 Music: Amazon Cloud vs. Google Play

I just bought Tal Ben Ari's Sheelá on MP3 from Amazon. I've been buying most of my music lately from the Google Play Store, but strongly dislike the limited number of downloads they allow a purchaser. Purchasers do buy the MP3s, right? And, no, I don't care about any fine print since the e-mail receipt which Google sends clearly states that the track is purchased. Quote: You've purchased a track on Google Play. 

The reason I switched to Google from Amazon was that Amazon no longer supports Linux, and forces Linux customers to download songs one at a time. PITA for albums.

So I can purchase the MP3s from Amazon and then download them to my Android. I probably want them there anyhow, and, of course, backed up in the cloud. Then I can sftp them to my desktop machine. Amazon doesn't get in the way, and the Google bean counters don't get involved.

An issue that may have me reconsidering the above is that Google says they have Tal Ben Ari's Sheelá at 320 kb/s, whereas the Amazon MP3s vary from 203 kb/s to 230 kb/s.

Note to Android users: AndFTP is a wonderful app, allowing me to connect to my desktop at home and a server at work wirelessly.

Personal Data in Amazon MP3s

In December I discussed the buyer ID data that Amazon is placing in MP3 files, noted that the standard tools seem to not notice these IDs, and expressed a desire to write a script to display these IDs. See http://martesmartes.blogspot.com/2010/12/need-to-write-my-own.html and http://martesmartes.blogspot.com/2010/12/personal-information-in-amazon-mp3.html.

First, the script:

// Time-stamp: <2011-05-27 22:23:37 jdm>

// JFlex script to look for UID tags in an MP3 received from Amazon. If
// such a tag is encountered, it is displayed. Otherwise, there is no
// output.

// Compiling (assuming JFlex is installed)
//
// jflex findUID.lex
// javac Yylex.java

// Running:
//
// java Yylex <MP3 file name>

// Bugs:
//
// A left angle bracket, <, within the UID will cause the tag to not be
// displayed.
// Even though the MP3s that I have seen with UID tags have the tags
// near the beginning of the file and only one UID tag per file, this
// searches the entire (possibly long) file and will display multiple
// UIDs if found. Though this is probably not a bug, it does cause a
// perceptible delay.

%%

%standalone

%unicode
%int

openAngle  = <
uid        = UID
stuff      = [^<]+
tagEnd     = "</UID"
closeAngle = >
tag        = {openAngle}{uid}{stuff}{tagEnd}{closeAngle}

%%

{tag} { System.out.println(yytext()); return 0; }

.     { return 0; }

\n     { return 0; }

\r     { return 0; }

As mentioned in the comments, this is a JFlex script. JFlex's lineage dates back to the standard Unix lexical analyzer-building tool, lex, which was superseded by flex. JLex has been well-known in the Java community for awhile, but work on it seems to have ceased. JFlex, however, appears to be an active project (and an Ubuntu package). Of course, it works on Windows, too.  See http://jflex.de/

It turns out that Amazon informs the consumer when an MP3 will contain identifying information. I did not notice this before Michael D. pointed it out to me in January. The Amazon notice is in the product details and says "Record Company Required Metadata: Music file contains unique purchase identifier." Then they have a "Learn More" link. This is what Amazon has to say:

Record Company Required Metadata

The record company that supplies this song or album requires all companies that sell its downloadable music to include identifiers with the downloads.  Embedded in the metadata of each purchased MP3 from this record company are a random number Amazon assigns to your order, the Amazon store name, the purchase date and time, codes that identify the album and song (the UPC and ISRC), Amazon's digital signature, and an identifier that can be used to determine whether the audio has been modified.  In addition, Amazon inserts the first part of the email address associated with your Amazon.com account, so that you know these files are unique to you. Songs that include these identifiers are marked on their product detail page on Amazon.com.  These identifiers do not affect the playback experience in any way.

The idea seems to be that the record companies are requiring Amazon to put the information in, and Amazon is being honest about what's in there, though most consumers likely never see this information and never notice the link to it.

A few comments are in order.

• My script displays the UID tag and contents, but does not modify or remove it. I have no intention of providing such a script.
• People share MP3s at their own risk. As someone who has made good money developing software, I understand their need to earn a living. I even understand, though am less sympathetic toward, the RIAA's outrageous damage claims in suits. Any individual's decision to share, or not, is between him, his conscience, and the RIAA.
• The UID is the user's Amazon user ID. On the MP3s containing the UID that I have, my script displays this:  <UID version="1">martensjd</UID>. That's me. 
• Amazon says there is other identifying information embedded in the MP3. Read the statement above. So stripping this out will not be sufficient to hide the original buyer.
• I would rather not have this in my media files, but I don't object strongly enough to go through the files stripping it all out.

Amazon MP3 Downloader

I get the feeling that
(a) Amazon cares little about Linux, and
(b) the Amazon MP3 downloader was done by very inexperienced or very poor developers.

Linux is a very small sliver of the market, so (a) is unsurprising.

My reason for casting stones at their developer is that the downloader does not work with 64b CPUs and now when I try to install it on a 32b Ubuntu 10.10 I get the message Dependency is not satisfiable: libboost-filesystem1.34.1. After installing version 1.42.0 of the libboost filesystem, I still get the error message. This strongly suggests that someone coded the dependency checks for only one version of the library, or wrote the code not considering the possibility that newer versions would be backward compatible.

I like Amazon, though I am done dealing with Amazon Sellers. Tonight Amazon had me thinking I might have to go elsewhere for MP3 downloads. However, a little googling and then a moment in the Ubuntu Software Center led to clamz. It appears there are a few other tools to do this, but clamz is the only one I see as an officially-supported Ubuntu package. And it works (or at least on the one album I pointed it at tonight).

I prefer using clamz over the Amazon downloader, because it's less closed software on my machine. Clamz likely does it's job, and nothing more. The Amazon downloader, for those lucky enough to have a system it works on, has always been an unknown factor--it downloads MP3s, but does it do something else? Probably not, but one never knows.

As an aside, the MP3s that I downloaded tonight do not have the same identifying information as the ones I wrote about last week. It may be obfuscated, encrypted, or just not present.

Personal Information in Amazon MP3 Files

A few days ago I wrote about Amazon placing personally-identifiable information within MP3 files. Here is an example, from near the beginning of an MP3 downloaded recently.

<?xml version="1.0" encoding="UTF-8"?>
<uits:UITS xmlns:uits="http://www.udirector.net/schemas/2009/uits/1.1" 
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <metadata>
    <nonce>Yvjd12Il</nonce>
    <Distributor>Amazon.com</Distributor>
    <Time>2010-10-24T04:41:17Z</Time>
    <ProductID 
       type="UPC" 
       completed="true">
      10731458698620
    </ProductID>
    <AssetID 
       type="ISRC">GBAAN0200016
    </AssetID>
    <TID version="1">
      plaIo2V1UdVjRvVYo2vBICme1kF4PYav
    </TID>
    <UID version="1"> MY USERID HERE </UID>
    <Media algorithm="SHA256">
      4fda5179408e867619d5321b804fd1d16cb1ffd4f3d3485b48c241f803444897
    </Media>
  </metadata>
  <signature 
     algorithm="DSA2048" 
     canonicalization="none" 
     keyID="9b3a698acfcfea37b486aba46bdfb50c92b8f7fe">MC4CFQCLUjy5GJIaXROMGuef/iTBI3ADngIVAI1ZVWo9+IA6FAVXQ5feBVbi3yH6
  </signature>
</uits:UITS>

I've done a little reformatting, replaced my user I.D. with a placeholder, and modified some hashes and keys, but you can easily get the basic idea. My advice is to be reluctant to share these files, or to strip the XML at the beginning.

This is a fairly recent change for Amazon. This information is not present in a song I downloaded from Amazon in August.

Need to Write My Own

MP3 files purchased from Amazon have identifying information within them, likely to catch, if not to actually deter, file sharing. At the beginning of the file is some XML including time and date downloaded, the Amazon user ID, a nonce, the distributer (Amazon.com in this case), and a digital signature (presumably so modification will be detected). Easytag does not display any of this XML data.

My intention was to place an excerpt here, but formatting XML within Blogger is more trouble than it's worth. Just view an MP3 from Amazon within an editor, e.g., emacs.

The upshot is that, since easytag doesn't display these tags, I'll have to write my own filter to do such.

Throughput from Amazon

I just downloaded an MP3 album and a couple MP3 tracks from another album from Amazon. With the first album, download speeds were about 500kB/s (over 4Mb/s). For the other two tracks, the download speed dropped to under 200kB/s. How come? I noticed it, but didn't give it much thought until receiving the e-mail confirmation from Amazon, and then it was clear. Amazon Digital Services was the seller of the album, and Sony BMG was the seller of the other tracks. They were coming from another server, one which was slower, at least in terms of the bandwidth it was able to give me at the time.