search

sandreas / tone

tone is a cross platform audio tagger and metadata editor to dump and modify metadata for a wide variety of formats, including mp3, m4b, flac and more. It has no dependencies and can be downloaded as single binary for Windows, macOS, Linux and other common platforms.
https://pilabor.com
Apache License 2.0
418 stars 17 forks source link

Tone tagging takes a long time for some files #58

Open jeff47 opened 1 year ago

jeff47 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@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 commented 1 year ago

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 commented 7 months ago

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

jeff47 commented 7 months ago

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

sandreas commented 7 months ago

@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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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

sandreas commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

Could they have been corrupted during the upload or download?

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

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

jeff47 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

@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 commented 4 months ago

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 commented 1 month ago

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 commented 1 month ago

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.