When a genuinely purchased/matched itunes .m4a file is edited with mp3tag, the file size becomes smaller. Even if I only edit the "ARTIST" tag. this happens for all m4a tracks. Why????
Note: If the track is already edited with mp3tag, then you won't notice a difference.
Eg.
Original Size - 8228376
After using mp3tag - 7905850
you can try it too, and i will happen the same if you notice.
thank you very much. just the information i wanted
is there any way to stop mp3tag from removing padding space from m4a files?
and also how is padding space added to these itunes music
At the moment you cannot stop Mp3tag from reducing the padding.
I have this problem too, and I already had 2 posts about it.
I hope Florian will have a word about this. 
To be honest: I cannot see any problem at all.
What do you win or loose by keeping the padding.
To me the extra padding looks absolutely superfluous.
A M4A file before and after a blank edit with Mp3tag (Comparison by using MediaInfo):
General
Complete name : ***\01 Roar.m4a
Format : MPEG-4
Format profile : Apple audio with iTunes info
Codec ID : M4A
File size : 7.61 MiB
Duration : 3mn 42s
Overall bit rate mode : Variable
Overall bit rate : 286 Kbps
Album : Roar - Single
Album/Performer : Katy Perry
Part/Position : 1
Part/Total : 1
Track name : Roar
Track name/Position : 1
Track name/Total : 1
Performer : Katy Perry
Composer : Katy Perry, Lukasz Gottwald, Max Martin, Bonnie McKee & Henry Walter
Genre : Pop
ContentType : Music
Recorded date : UTC 2013-08-12 07:00:00
Encoded date : UTC 2005-04-22 04:06:38
Tagged date : UTC 2013-08-11 21:02:56
Copyright : ℗ 2013 Capitol Records, LLC
Cover : Yes
Rating : None
AppleStoreAccount : ***
AppleStoreCatalogID : 685726026
AlbumTitleID : 64387566
cmID : 296059745
PlayListID : 685725696
GenreID : 14
AppleStoreCountry : United States
PurchaseDate : 2013-08-12 04:02:39
Vendor : Universal:isrc:USUM71308669
iTunMOVI : <?xml version="1.0" encoding="UTF-8"?> / <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> / <plist version="1.0"> / <dict> / <key>asset-info</key> / <dict> / <key>file-size</key> / <integer>7979826</integer> / <key>flavor</key> / <string>2:256</string> / </dict> / </dict> / </plist>
Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 3mn 42s
Bit rate mode : Variable
Bit rate : 256 Kbps
Maximum bit rate : 294 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 7.04 MiB (93%)
Language : English
Encoded date : UTC 2005-04-22 04:06:38
Tagged date : UTC 2013-08-11 21:02:56
General
Complete name : ***\01 Roar (Edited with Mp3tag).m4a
Format : MPEG-4
Format profile : Apple audio with iTunes info
Codec ID : M4A
File size : 7.26 MiB
Duration : 3mn 42s
Overall bit rate mode : Variable
Overall bit rate : 273 Kbps
Album : Roar - Single
Album/Performer : Katy Perry
Part/Position : 1
Part/Total : 1
Track name : Roar
Track name/Position : 1
Track name/Total : 1
Performer : Katy Perry
Composer : Katy Perry, Lukasz Gottwald, Max Martin, Bonnie McKee & Henry Walter
Genre : Pop
ContentType : Music
Recorded date : UTC 2013-08-12 07:00:00
Encoded date : UTC 2005-04-22 04:06:38
Tagged date : UTC 2013-08-11 21:02:56
Copyright : ℗ 2013 Capitol Records, LLC
Cover : Yes
Rating : None
AppleStoreCatalogID : 685726026
AppleStoreAccount : ***
PurchaseDate : 2013-08-12 04:02:39
iTunMOVI : <?xml version="1.0" encoding="UTF-8"?> / <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> / <plist version="1.0"> / <dict> / <key>asset-info</key> / <dict> / <key>file-size</key> / <integer>7979826</integer> / <key>flavor</key> / <string>2:256</string> / </dict> / </dict> / </plist>
AlbumTitleID : 64387566
cmID : 296059745
PlayListID : 685725696
GenreID : 14
AppleStoreCountry : United States
Vendor : Universal:isrc:USUM71308669
Audio
ID : 1
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 3mn 42s
Bit rate mode : Variable
Bit rate : 256 Kbps
Maximum bit rate : 294 Kbps
Channel count : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Stream size : 7.04 MiB (97%)
Language : English
Encoded date : UTC 2005-04-22 04:06:38
Tagged date : UTC 2013-08-11 21:02:56
Differences after editing:
Bold is destructive behavior, in my opinion.
Each person has different viewpoint for a subject.
With me; music is my life, my everything. Over the years, I used Mp3tag for my perfect music collection. It handles MP3, FLAC and APE files natively without any problems. Then M4A is a next generation format with many advantages.
While you may not care deeply about your music files or tags, but I do. I really want my files to be as original as available. I had edited many M4A files without noticing anything. One day like any other days; I discovered that after small edits with few M4A files by using Mp3tag, the file sizes are smaller than I last remembered. First, I got grief with myself for doing something bad to my files, it was very unpleasant. I eventually made up my mind and retested a blank edit with an original M4A file and the file size is smaller, too. This led to conclusion that the fault is Mp3tag. After I discovered this; with editing M4A files, I had to choose between keeping original files or editing them with Mp3tag. I chose both; one copy is kept original, one copy is edited with Mp3tag.
If the reasons that make the files are smaller are because "the padding". Then, "keeping the padding" wins everyone. Files from iTunes Store have it, so let them be.
Conclusion: The ones do not need it will not care about it. The ones need it there to make the file "more original" will be so happy if this problem is fixed.
And no one loses in this battle, boy!
Just a philosphical approach: as soon as you start modifying a tag, it is not the original any more.
It is still not plausible for me why the file size of all attributes should set the difference between the original and something else.
There have been treads in this forum that noted that although a good chunk of data got removed (e.g. the cover picture) the file size did not change. So apparently both results are possible.
But common to all is: a user modified the tags and created a new version.
I still do not see the bug.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.