Convert decimal to hex?

Is there a way to convert %_length_seconds% to a hexadecimal value? I'm trying to create fake %comment itunsmpb% tags, and if I use a fake value sometimes iTunes interprets the fake value as the actual length of the track.

Do you know this?
http://www.hydrogenaudio.org/forums/index....8231&st=136

DD.20100107.0957.CET

Yeah, my need for this doesn't really have anything to do with actually having a gapless track. The short story is that I need to fool iTunes into thinking it doesn't have to do gapless analysis and just read an existing tag.

The longer story is this: I have my main library at home on a Mac and a subset of files on my XP admin machine at work, which I can access through a company VPN. I developed several AppleScripts that work keep the tags for each library synchronized. The system generally works fine EXCEPT that the iTunes library at home wants to do gapless analysis on all the files at work - something like 14,000 files. For some reason, gapless analysis on remote files is sssss......llll......ooooo.......wwww. And it eats most of the processor power while it does this, making the computer sluggish and freezing the user out for several minutes at a time. The app takes about 20-60 seconds per file to analyze (which is weird because it's not a slow network - it'd take about 5-7 seconds to copy the entire file or start playing the remote copy. And despite a lot of user complaints about this over the past few years, Apple will not allow users to permanently disable this, even if they have no interest in the feature.)

Another bug/feature introduced recently causes iTunes to reassign the location of a track in the library to a local copy of a file if the remote file was ofefline. Prior to iTunes 9, if I launched iTunes without having the shared drive at work mounted, iTunes would just show the track as unavailable, but it would become available again the next time iTunes was launched with the share mounted. Now, instead of showing offline files, it changes the track reference to the local copy of the file - even if another track already refers to the file - with no way of changing it back. So if I just leave it to churn a couple days through all the backlog, the minute my net connection fails or the VPN at work drops me, my entire library will get corrupted.

However, if %comment itunsmpb% already has a value, most of the time iTunes just copies that into its local library, which is much faster than calculating it from scratch. But what I just discovered is that sometimes iTunes uses the value encoded in the gapless tag to determine what the length of the track is. So...I just need to find a way to calculate part of the tag based on the actual track length, which means I need to convert a decimal value to hex.

So can we do that?

Torc, did you read the given URL's content from top to down?

Me, not. But I detected several hints which stay against your wish.

If I understand well, the tag field "comment itunsmpb" is needed to control gapless playing.
So it has to know about the actual length of the music data on a per sample basis.

Mp3tag has no output feature, which can show the user the actual number of samples in the currently selected music file.
Mp3tag is able to deliver the sample rate by system technical info field %_samplerate%, so you might be able to calculate the samples by "samples" = "length in seconds" * "samplerate".
But sadly this will not give accurate results in any case, because Mp3tag returns the music data "length" of a music file as rounded by seconds (not sure if rounded up or rounded down) as a "Length (in seconds)" value.
Using current version of Mp3tag I see no way how to calculate the actual sample size of a music file. You cannot rely on those calculations because of the rounded value "length in seconds".

  1. The tag field "comment itunsmpb" stays possibly for something like "Comment iTunes Sample B...".
    This tag entry holds the number of samples of the music part within the file.

If you only want to write a "fake value" into the tag field "comment itunsmpb", then you can search the internet for "comment itunsmpb" content strings, there are many.

Or just copy one from the given URL from above, e. g.:
00000000 00000210 000007C8 000000000006BAA8 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

I would expect, that this entry will fake, possible too much. In the case that iTunes works with this value for it's own user display or sound play actions, then such a fake will guide you into heavy troubles.

  1. So what can you do?
  • Ask Mp3tag developer Florain Heidenreich, if he is willing to support this "comment itunsmpb" value by native Mp3tag system technical field.

  • May be he can return the actual number of samples by a native Mp3tag system technical field.

  • Try to find a third party tool that can do what you want.

Hint from atomicparsley: "A new style of metadata emerged with the foobar2000 0.9.x series. For whatever reason, this style typically duplicates the iTunes-style metadata."

DD.20100108.1510.CET

Proposal:
You can use foobar2000 to add a new metadata tag field ITUNSMPB using this scripting line:
00000000 00000000 00000000 $hex(%length_samples%,16) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

alternative
$hex(0,8) $hex(0,8) $hex(0,8) $hex(%length_samples%,16) $hex(0,8) $hex(0,8) $hex(0,8) $hex(0,8) $hex(0,8) $hex(0,8) $hex(0,8) $hex(0,8)

Try out what iTunes will do with a file which contains such a faked entry.

DD.20100108.1834.CET

First, thank you for the reply, it is definitely appreciated!

True, but the only effect that affects me of this being inaccurate is that iTunes lists the track with an incorrect length. If that length is too small, playback is truncated, so mainly I want to avoid that. If it's too big, it just means the playback progress bar will be incorrect. It's not going to bother me if the length is a little off (in fact, I'll probably add 500ms in padding just to be safe).

I did test this with fake data, doing manual calculations for a few tracks, so I know it does work well enough for what I need. But without an automated method of doing this, I won't be able to fake all the tracks (or just insert a value I know is larger than the track and accept that the times are going to be wrong in iTunes).

Once the library at home has finished updating (which will take about 12 hours with the fake tags instead of 12 days), or if this causes other problems, I'll just remove the fake tags. (And I do have safety copies of everything, just in case!)

Excellent! I will try that sometime next week. But just so I know, does the $hex() function work in mp3tag? As you mentioned, something like $hex(($mul(%_length_seconds%,%samplerate%)) will give a close approximation, which should be good enough for what I want to do.

You can give order to build a $hex() function to Mp3tag Developer Florian Heidenreich, do not forget to donate :rolleyes:. It's a standard functionality, so it should be easily to implement. For my part I would like to see the %length_samples% system info in Mp4tag too.

DD.20100109.0133.CET