Tone tagging takes a long time for some files

[jeff47]

On a number of files in my library, tone takes an excessively long time... 45 minutes or more. The files aren't unusually large, and size doesn't seem to be a predictor. I tried running tone with --debug but there was no additional data that was presented. For most of my library, it takes only a few seconds per file.

Are there some additional flags or tips you can suggest to help troubleshoot this problem? I thought it might be a corrupt m4b, but I've gone back and re-encoded using m4b-tools and the result is the same.

[sandreas]

@jeff47 Thanks for reporting. I already heard of this. Would you be able to (non publicly) provide a file that takes this long so that I can do further investigation?

If so, I would invite you to a private github repo where you could upload the file, so we could discuss this with the atldotnet maintainer (the tagging lib that is used in tone)

[jeff47]

@jeff47 Thanks for reporting. I already heard of this. Would you be able to (non publicly) provide a file that takes this long so that I can do further investigation?

If so, I would invite you to a private github repo where you could upload the file, so we could discuss this with the atldotnet maintainer (the tagging lib that is used in tone)

Yes, I'd be happy to. I'm out of town for a few days but when I get back, I'll try to identify a file that reproducibly causes a slowdown.

[sandreas]

Yes, I'd be happy to. I'm out of town for a few days but when I get back, I'll try to identify a file that reproducibly causes a slowdown.

Awesome, thank you... let me know if you are ready to share it.

[sandreas]

@jeff47 Did you ever get back to town? I'm a bit worried...

[jeff47]

Haha, sorry! Life got in the way. Let me go back through and see if I can find a troublesome file.

[sandreas]

@jeff47 ok let me know. I'm preparing a new release with lots of improvements in atldotnet, so maybe this will be fixed with these, too.

[jeff47]

@jeff47 ok let me know. I'm preparing a new release with lots of improvements in atldotnet, so maybe this will be fixed with these, too.

OK, can you point me where to upload a file? I think I've got one.

[sandreas]

OK, can you point me where to upload a file? I think I've got one.

I've invited you to a private repo, then you can share a One Click Hoster file (e.g. mega.io). I'll have to point out that these files are only to investigate the bug and not meant for any kind of file sharing, so please upload only the files necessary to reproduce it :-) Thank you.

[jeff47]

OK, can you point me where to upload a file? I think I've got one.

I've invited you to a private repo, then you can share a One Click Hoster file (e.g. mega.io). I'll have to point out that these files are only to investigate the bug and not meant for any kind of file sharing, so please upload only the files necessary to reproduce it :-) Thank you.

Please let me know when you've grabbed the files so I can remove them from Mega.

[sandreas]

done, thank you very much. I'll try to investigate... could you provide a full command line that takes long?

[sandreas]

@jeff47 On Linux (Ubuntu) I get the following error when trying to tag these files:

tone tag --meta-album test test.m4b 
Stream was not readable.
   at System.IO.BinaryReader..ctor(Stream , Encoding , Boolean )
   at System.IO.BinaryReader..ctor(Stream )
   at ATL.AudioData.IO.MP4.read(Stream source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MetaDataIO.prepareWrite(Stream r, TagData tag)
   at ATL.AudioData.IO.MetaDataIO.Write(Stream s, TagData tag, ProgressToken`1 writeProgress)
   at ATL.AudioData.AudioDataManager.UpdateTagInFile(TagData theTag, TagType tagType, ProgressManager writeProgress)
Cannot access a closed file.
   at System.IO.FileStream.get_Length()
   at ATL.BufferedBinaryReader..ctor(Stream stream)
   at ATL.AudioData.IO.APEtag.read(Stream source, ReadTagParams readTagParams)
   at ATL.AudioData.IO.MetaDataIO.prepareWrite(Stream r, TagData tag)
   at ATL.AudioData.IO.MetaDataIO.Write(Stream s, TagData tag, ProgressToken`1 writeProgress)
   at ATL.AudioData.AudioDataManager.UpdateTagInFile(TagData theTag, TagType tagType, ProgressManager writeProgress)

Something with these files seems to be wrong. Are you using linux?

[jeff47]

Hmm, they work here. Could they have been corrupted during the upload or download? I can try to send them again -- do I need a new repo invite?

[sandreas]

Could they have been corrupted during the upload or download?

@jeff47
Possible, but unlikely... Please answer the following questions:

• Which OS and Arch are you using (e.g. Win 10 + x64 - it may be that tone is acting different on another OS)?
• What is the shasum of your file (shasum -a 256 file.m4b - just to verify it has not been corrupted)

You can just reupload and update your issue, you are still member of the private repo :-)

[jeff47]

I'm running Ubuntu on a 64 bit system. It's tone 0.1.5.

I renamed the files when I uploaded them to (slightly) obfuscate the contents, and I didn't keep track of which was which.

But if doing it by file size is ok, then:
b9664e4d113e34ebd3dbb4d201c7d47a180b44d54e1b6ce52c9d5c69c601dcf7 was 274 Mb
b5f9c52e1855f7db8a8e97ce756f2c9ed2f8a771b8089cd99b04b89658e2bef0 was 505 Mb
6cb7443778c2b672b6107702286a92cf6254c5fe027831f709578ad95b7ffbd6 was 261 Mb

[sandreas]

But if doing it by file size is ok, then:

Ok, it seems we found the problem:

dc18bf16b0a3f645f5faabbbdad4b13b9cd2e6ef481a9b0b4482227f89ee1db3 => 274M
f159c8ad8ae382ebe440572ebfdd78d7450651a5b5c4ecd7d18dc33fe2dd4a4e => 505M
5d6ae27e795fc8f2e1d48ba91cc95ca5c0913a57aeda0164c910310dd0d7038d => 261M

None of the files I downloaded has the original content. Very strange... Well, I would say you reupload the files and I download them ensuring the hash is correct :-)

I'm really sorry you have to do it again... can't say what happened.

[sandreas]

@jeff47
tone 0.1.6 is out. Since it is the first release after a long time, this issue may have been fixed with the new atldotnet release. I would love to get feedback, please backup your files.

[sandreas]

tone 0.1.7 is out, no feedback - I'm going to assume this is fixed. Feel free to reopen the issue, if not.

[jeff47]

It's still happening, but I think I have a clue! I have some m4b files where tone runs just fine on the initial file, but if I try to add a tag after telling Audiobookshelf (ABS) to embed tags, it takes a long time. Could it be something to do with the tag structure that ABS is creating? Happy to share an untagged/tagged set so you can compare, if you can provide a private way to share. (It's a large file, ~1 Gb, I can try to find a smaller example but I don't have one identified right now.)

[sandreas]

It's still happening, but I think I have a clue! I have some m4b files where tone runs just fine on the initial file, but if I try to add a tag after telling Audiobookshelf (ABS) to embed tags, it takes a long time. Could it be something to do with the tag structure that ABS is creating?

Possibly. I'll get back to you soon, some other things to do atm. I'm going to prepare a github invite for a private repo to share the files.