Beta1 didn't crash but some flac files did not fully convert to mp3 (playable but random file lengths). Beta2 will crash everytime when encoding is started in every output type.
Hi Tim,
thank you for your bug report and for the minidump file. This seems to be a bug in libsndfile that occurs when decoding FLAC files. I already downgraded libsndfile from version 1.0.28 to 1.0.27, where the bug is not appearing. Unfortunately libsndfile has no newer version where this bug is fixed. For beta 3, which is released in a few days, the error should be gone. You can take the libsndfile-1.dll from previous versions (e.g. from the zip package) and put it in the winLAME application folder to work around this issue.
About the "playable but random file lengths"... this happens when you are encoding to mp3 using VBR, since the player can't determine the length of the audio track from its file size (because all mp3 frames are variable). LAME introduced the LAME Info tag, where the track length is stored. Most players (e.g. foobar2000) can read the tag and properly show the correct track length. Also, in some cases the LAME Info tag isn't written. Which mp3 encoding settings did you use? A preset?
Regards,
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Michael,
It's good to see a dev on the case so quickly ;-)
I have wrung the neck out of the v1.0.28.0 libsndfile-1.dll for the past hour or so by running through each encoder setting ten times. That includes each of the custom fast, standard and high modes, with two passes through each of the eight kbps rates. At this point I didn't see any added value in running through each of the 0-9 Quality options as there was no apparent pattern emerging. I.e. GPF's were occurring randomly, whether the application was running as new instance or a second/third encode within the same session. BTW, the three More Options check boxes had no effect on the randomness either. I did run through a smaller subset of tests with the pre-release v1.0.29.0 as well but no difference their either. Summary? Buggered if I know what causes the overflow so sorry I can't really offer anything of use.
Good luck with new version,
Tim.
P.S. v1.0.27.0 = all ok. No crashes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Tim,
libsndfile is used as input file module in your scenario, and I guess you used LAME as output module. The crashes don't depend on the settings you used on the output module. For the beta 3 version I reverted back to libsndfile 1.0.27, where the crashes don't occur. I'm waiting for a new libsndfile version that fixes the crashes and will release a future winLAME version then. You can try out the beta 3 version release right now, if you want.
Cheers,
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Beta3 looking good. No errors ✔.
One thing I did forget to mention is that if the destination file is locked (in my case being played with MPC-HC) and the encode run, completion status is marked as 'completed'. The conversion may have completed but the file could not be created due to its locked state.
Cheers.
Tim.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Tim,
I just released winLAME 2018 beta 1. For the last bug you reported, this should be fixed, too. Every task that reports an error should now be marked as "Failed", with an error text in the task description below the list.
Thanks for reporting the issues!
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Michael,
I have just upgraded to winLAME 2018 beta 1 (fyi although the MSI has actually detected it's an upgrade, all dialog text still says it's an 'install') and have tested with the exact same flac that caused the original bug. All good there. The error reporting panel is working well as the flac was in the same folder as the exe and the exe didn't have permisson to write there. Re-run the exe as Administrator and the conversion suceeds just fine.
Thank you.
Tim.
Hi Tim,
thanks for the confirmation! Closing this ticket.
The History page was meant for people who want to know about the last 19 years of what happened. The "news" page should cover the last year :-) but I might update the history, too. Thanks!
-Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Tim,
thank you for your bug report and for the minidump file. This seems to be a bug in libsndfile that occurs when decoding FLAC files. I already downgraded libsndfile from version 1.0.28 to 1.0.27, where the bug is not appearing. Unfortunately libsndfile has no newer version where this bug is fixed. For beta 3, which is released in a few days, the error should be gone. You can take the libsndfile-1.dll from previous versions (e.g. from the zip package) and put it in the winLAME application folder to work around this issue.
About the "playable but random file lengths"... this happens when you are encoding to mp3 using VBR, since the player can't determine the length of the audio track from its file size (because all mp3 frames are variable). LAME introduced the LAME Info tag, where the track length is stored. Most players (e.g. foobar2000) can read the tag and properly show the correct track length. Also, in some cases the LAME Info tag isn't written. Which mp3 encoding settings did you use? A preset?
Regards,
Michael
Hello Michael,
It's good to see a dev on the case so quickly ;-)
I have wrung the neck out of the v1.0.28.0 libsndfile-1.dll for the past hour or so by running through each encoder setting ten times. That includes each of the custom fast, standard and high modes, with two passes through each of the eight kbps rates. At this point I didn't see any added value in running through each of the 0-9 Quality options as there was no apparent pattern emerging. I.e. GPF's were occurring randomly, whether the application was running as new instance or a second/third encode within the same session. BTW, the three More Options check boxes had no effect on the randomness either. I did run through a smaller subset of tests with the pre-release v1.0.29.0 as well but no difference their either. Summary? Buggered if I know what causes the overflow so sorry I can't really offer anything of use.
Good luck with new version,
Tim.
P.S. v1.0.27.0 = all ok. No crashes.
Hi Tim,
libsndfile is used as input file module in your scenario, and I guess you used LAME as output module. The crashes don't depend on the settings you used on the output module. For the beta 3 version I reverted back to libsndfile 1.0.27, where the crashes don't occur. I'm waiting for a new libsndfile version that fixes the crashes and will release a future winLAME version then. You can try out the beta 3 version release right now, if you want.
Cheers,
Michael
Beta3 looking good. No errors ✔.
One thing I did forget to mention is that if the destination file is locked (in my case being played with MPC-HC) and the encode run, completion status is marked as 'completed'. The conversion may have completed but the file could not be created due to its locked state.
Cheers.
Tim.
Hi Tim,
I just released winLAME 2018 beta 1. For the last bug you reported, this should be fixed, too. Every task that reports an error should now be marked as "Failed", with an error text in the task description below the list.
Thanks for reporting the issues!
Michael
Hi Michael,
I have just upgraded to winLAME 2018 beta 1 (fyi although the MSI has actually detected it's an upgrade, all dialog text still says it's an 'install') and have tested with the exact same flac that caused the original bug. All good there. The error reporting panel is working well as the flac was in the same folder as the exe and the exe didn't have permisson to write there. Re-run the exe as Administrator and the conversion suceeds just fine.
Thank you.
Tim.
P.S. This page...
https://winlame.sourceforge.io/history.html
might include a ref to your latest work?
Hi Tim,
thanks for the confirmation! Closing this ticket.
The History page was meant for people who want to know about the last 19 years of what happened. The "news" page should cover the last year :-) but I might update the history, too. Thanks!
-Michael