Hello, while tagging classical music already ripped and tagged by dbPoweramp i get a lot of errors/warnings like
Hi Flac files have different block types for storing different data, e.g text comments are stored in block 4, images in block 6, and audio seek table in block 3.
Thankyou for running Create Support Files
If you could send me (using email or service like dropbox) an example of one file reporting the block 79 error and another reporting block 93 error I can test them. Its weird that you say the files were ripped and tagged by dbPoweramp because I haven’t seen this error before, certainly dbPoweramp doesn’t usually add these block types, I would have expected that they come from another application. Do you have some kind of dbPoweramp plugin installed ?
All the errors come from only a few albums, so could it be these ones were not ripped by dbPoweramp ?
In the meantime the following workaround should work for you:
Thankyou for sending the original (okay) flac files, and the files after they have been tagged by SongKong
When I look at the Königlicher Marsch des Löwen file I can see SongKong has added lots of artwork/images and when I try and read it it fails round that point, so I wonder if there is a set of circumstances than can cause SongKong to write files incorrectly, but when I match the original files with SongKong I cannot get the failure to occur, perhaps because my SongKong config is different to yours.
Can I check after matching the files with SongKong, did you use any other tool to edit them before they became unreadable with SongKong ?
Can you see if you can reproduce as follows:
What I am trying to find out with this test is does it now complain about the file is unreadable, so we have a reproducible test case, and shows problem is caused by SongKong, or do we not.
I have done all the steps until cleaning the Database - when i tried to run SongKong again it detected no readable files! Although i created support files.
1st edit: The file in the folder is readble - i played it just with “Groove Music” and checked the ID tags with dbPoweramp tag editor.
2nd edit: With empty database i just run SongKong once again on the original path - now with no errors, but with lots of new tag corrections?! I created Support Files again.
Hi received your logs, but with report 37 the file could be loaded but there was some issue connecting to server and so the song was not actually matched. Then in report 38 it did actually match the song and add the data, then report 39 was ran against a different folder. So I am afraid the test is incomplete I need you to empty database and try again to load the file (now it is fully tagged) to see if SongKong can still read it or if it is now corrupt.
Ok, later on I’ll try to complete the test procedure as mentioned before.
But curiously yesterday I once again cleared the database, killed all tagged files, copy the originals back to the same folder and run SongKong with no errors or warnings! Besides some results were different to previously created.
Bubblefish
Because if SongKong is causing the problem it does not know it is, so hence there would be no warnings the first time, only subsequently.
Sometimes we can get improved results second time round based on the data added first time. In your case it looks like more acoustids were created (maybe temporary issue connecting to acoustid server) and this led to more data being added.
So,I did the test - and once again SongKong couldn’t read the same file after cleaning the database (Support Files created):
Okay, thankyou that confirms an Issue with SongKong
I am thinking may be connected to this issue that I fixed nearly a year ago
I have raised an issue on SongKong - https://jthink.atlassian.net/browse/SONGKONG-1954 and this is top priority issue.
ok, hope you find it!
I think I have, I managed to replicate your issue when I increased the max image size on the Artwork tab from 1000 to 5000, an image of the composer Camille Saint-Saëns caused your file to be unreadable, the image was 4664 x 4664 pixels in size but more importantly 19,104,574 bytes in size (i.e 19mb)
It seems the limit for an image is about 16 mb - https://hydrogenaud.io/index.php?topic=60122.0 confusingly in Flac a METADATA_BLOCK_PICTURE block has a 32bit field to store the length of the data (i.e about 2GB), but its METADATA_BLOCK_HEADER total data length field is only 24bit, and this limits max size to 16,777, 215 bytes.
I started with original file again and set max image size to 4000 and that reduced the image size to just 3,133,177 bytes and then the file was readable okay.
So now need to devise a fix to prevent images larger than the limit being set, the tricky thing is you cannot just say create an image less than 16.7 mb. You can only say create image less than x by y pixels and see by trial and error if small enough, alternatively keep image size but modify compression settings.
Okay, now fixed - should be a new release of SongKong containing this fix later on this week.
