Help!! Changing file size


#1

I need an Action that changes file size without altering existing tags or audio. I have tried setting bulky dummy comments, but this often fails... perhaps because it just consumes padding already in the file. Can anyone suggest a fix? E.g. some way in an Action of compacting the tag record... whilst retaining existing tags?

Any ideas greatly appreciated... since I am desperate for this as the last known workaround to Windows Media Player sync's loss fo tracks due to false detection as duplicates of tracks having the same size and filename - even though different folder and metadata!

Thanks.


#2

I think this is impossible.

Have you tried to let AlbumArtFixer run over your WMP library? This ususally finds tracks that are not in the right place (it pretends to look for Albumart but also looks for other inconsitencies.)
As the rubbish entries are of no use anyway, you can delete them from wmp without any remorse and let wmp build up its library again. Then everything should be back to normal.


#3

I think this is impossible.

Well the fact that I have it partly working - by adding unused tags such a comment - suggests to me it is possible.

Have you tried to let AlbumArtFixer run over your WMP library? This ususally finds tracks that are
not in the right place (it pretends to look for Albumart but also looks for other inconsitencies.)

There are not inconsistencies in the files. The problem is a fault in WMP sync.

As the rubbish entries are of no use anyway, you can delete them from wmp without
any remorse and let wmp build up its library again. Then everything should be back to normal.

Thanks for the suggestion but deleting and rebuilding does not solve the problem.


#4

Hmm, this sounds to be a rather worst thing with the WMP and your idea to trigger the WMP sync feature by changing the music file's size by enlarging the inner tagging data seams to do the trick for you. Sadly the padding feature of some tag types makes the trick not so easy, because you have no chance to say how many padding bytes are used resp. are still unused in a specifically tagged musc file.

Well, you might use an action "Format Value" along with the function $repeat(a,n) to create a tag field of such a big length that eatens up all existing padding and would cause Mp3tag to create a new padding area in order to outwit WMP.

As long as the WMP takes the whole filesize into account, this workaround might work.
If WMP looks only to the music data (by creating a fingerprint checksum) you are lost.

DD.20100626.0451.CEST


#5

I get frequently weird entries if WMP just tired to append its library while edited the files and changed the filenames. WMP then either does find the files any more (which is true as they have a different filename) or the tags suggest that the track belongs to the wrong album.
To me this sounds just like your problem.
So, what I do instead of messing about with tags is that I let run Albumartfix to find these astray tracks. Albumartifix checks whether files are in the same folder and stumbles over these that wmp filed for the wrong album.
Then I go to wmp, open that album, also have the path displayed and sort by path.
Now I delete the tracks from the wrong path without deleting the tracks from the harddrive.
Once Albumartfixer has run through the library I start a run in WMP (F3 in Windows XP and Vista) and the library gets extended by the formerly deleted tracks and wmp is back to sync.
I cannot offer more.


#6

S adly the padding feature of some tag types makes the trick not so easy, because you have no
chance to say how many padding bytes are used

I think it would be sufficient for me to be able to remove the padding.

Well, you might use an action "Format Value" along with the function $repeat(a,n) to create a tag
field of such a big length that eatens up all existing padding and would cause Mp3tag to create a
new padding area in order to outwit WMP.

Thanks, D - I found 10000 chars insufficient but 60000 chars is sufficient on test files.

($repeat(X,100000) failed - an MP3tag limitation??)

BUT... without knowing the max padding size, I cannot say this will work in general.

And applying this unconditionally risks creating a file size equality. Can anyone think of a way to apply this conditionally? To only files that are the same size as another? I think this would be possible using an Action Group doing Export then Tag from textfile... except that last time I tried similar, I found Mp3tag won't do these two Actions in this order. And ideas?

As long as the WMP takes the whole filesize into account, this workaround might work.

It does.

If WMP looks only to the music data (by creating a fingerprint checksum) you are lost.

If it created a fingerprint checkum I would probably be fine, since the audio is different. I was disppointed when I found that it marks audio the same apparently on considering only the nunber of bytes!


#7

I find within each set sufferring from the problem, the max size difference ranges from -14,892 to 29,784 (in fact all differences are mutiples of 14,892 - WMA encoding chunk size I guess).

And in each case I have tried I have found that adding 60,000 chars of Comment is sufficient to change the file size, though whether by as much as 60,000, I am unsure.

Based on this, here's the solution I've deployed to ensure each set contains no two files of the same size. In Mp3tag I add 60,000 chars to the second file and twice as many to the third, using this Action:

Format Value
COMMENT
$repeat($replace(%_directory%,Loud,,Medium,M,Quiet,Qq),60000)

This command line using Unix tools reports the number of duplicates remaining, hopefully zero:

dir /s /a-d | egrep -e ".wma$" | cut -c 27- | sort | uniq -c | egrep -v -e "^ *1 " | wc -l

This solution could fail on some suplicates (e.g. that already have large padding) and even create some (that coincidentally difference by the amount of the adjustment). Any improvements gratefully receied.