Last active
June 18, 2024 17:49
-
-
Save torque/4361328 to your computer and use it in GitHub Desktop.
Script to strip various iTunes atoms from purchased AAC files via AtomicParsley.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#!/usr/bin/env ruby | |
# usage: stripiT.rb file1.m4a file2.m4a file3.m4a | |
# automatically outputs to file1 - stripped.m4a, file2 - stripped.m4a, and so on. | |
# Script to remove extraneous/unwanted atoms from iTunes purchased files by way of AtomicParsley. | |
# Output should be comparable to the atoms left over after reencoding the file in iTunes itself. | |
# I only care about songs, so I have no clue how well this applies to video files | |
# Some information taken from: https://code.google.com/p/mp4v2/wiki/iTunesMetadata | |
# atoms to remove: | |
# moov.udta.meta.ilst.apID # apple account email address | |
# moov.udta.meta.ilst.atID # artist-track ID | |
# moov.udta.meta.ilst.cnID # iTunes Catalog ID | |
# moov.udta.meta.ilst.geID # genre ID | |
# moov.udta.meta.ilst.plID # playlist ID (identifies album) | |
# moov.udta.meta.ilst.sfID # iTunes store identifier (location/number) | |
# moov.udta.meta.ilst.cprt # copyright information | |
# moov.udta.meta.ilst.flvr # bitrate/video size information? | |
# moov.udta.meta.ilst.purd # date purchased | |
# moov.udta.meta.ilst.rtng # Explicit/Clean information | |
# moov.udta.meta.ilst.soal # Album sort name | |
# moov.udta.meta.ilst.stik # media type information | |
# moov.udta.meta.ilst.xid # vendor xID | |
# moov.udta.meta.ilst.----.name:[iTunMOVI] # some embedded plist thing, contains filesize and flavor. | |
# moov.trak.mdia.minf.stbl.stsd.mp4a.pinf # purchase information? | |
# Notes: | |
# [pinf] contains personal info, such as the name attached to the apple account. | |
# It requires --DeepScan to remove. | |
# [apID] contains the email address attached to the itunes account used to purchase. | |
# [purd] contains date/time of purchase | |
# [sfID] contains store information, including the country it was purchased in. | |
ARGV.each {|track| | |
infile = File.expand_path( track ) | |
outfile = infile.gsub( /\.([^\.]+?)$/, " - stripped.\\1" ) | |
command = "AtomicParsley \"#{infile}\" --DeepScan --manualAtomRemove \"moov.trak.mdia.minf.stbl.stsd.mp4a.pinf\"" | |
["apID","atID","cnID","geID","plID","sfID","cprt","flvr","purd","rtng","soal","stik","xid ","----.name:[iTunMOVI]"].each {|atom| | |
command += " --manualAtomRemove \"moov.udta.meta.ilst.#{atom}\"" | |
} | |
command += " -o \"#{outfile}\"" | |
process = IO.popen( command ) | |
while ( status = process.gets ) | |
puts( status ) | |
end | |
} |
I'm experiencing something perplexing with this script. Mostly works really nicely, but on about 50% of purchased items I've checked, it removes all the Apple metadata except for the name associated with the iTunes/Apple Music account. Yes, the Apple username is gone (email address), but not the first and last name of the purchaser. And I can't see any pattern in terms of when the item was purchased from Apple. I have items purchased in the last 6 months that it's removed my actual name from. And 5 year-old purchases it failed on. No error messages of any kind are seen. It runs, creates the -stripped file, and that one piece of metadata remains.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Sorry for the slow reply. Github doesn't seem to notify me of comments on gists. Anyway, I can't help you, unfortunately, as I haven't experienced that particular problem myself. I only have a few songs I've run this on, and they seem to work fine on my phone. It's possible one of the atoms that gets stripped contains important metadata, but I find that unlikely. When I wrote this, I compared the results to the output of reencoding in iTunes (which, at least at the time, did not preserve the store information—not sure if it still does that) and found them to be the same, at least in terms of metadata. I suppose it's possible that AtomicParsley could be doing something weird to the file, too. It might be worth comparing the input and the output in a hex editor (e.g. Hex Fiend) or similar to see if anything besides the obvious has been removed or rearranged.
If you figure(d) out the problem, let me know. I'm kind of curious.