Closed ghost closed 4 years ago
I would have shown a screenshot of how it looked when it worked but I didn't think about needing it at the time because I didn't anticipate a permanent breakage.
I think I might have found a workaround by using a shell command to call the program it does work in and reading the output from it back into the InForm version.
That's most curious. I could have a closer look if you're willing to share your files (mp3 included).
Also: which build of InForm?
aaaaaaaaaaaaah, I have a suspicion. try this:
FreeFileHandle% = FREEFILE
OPEN SongFile$ FOR BINARY AS #FreeFileHandle%
Then replace all instances of hard-coded "1" (in LOF(1)
, GET #1
, CLOSE #1
) to FreeFileHandle% (LOF(FreeFileHandle%)
, GET #FreeFileHandle%
, CLOSE FreeFileHandle%
)
That didn't work either. It behaved the same way with either showing nothing in the labels at all or showing garbled text. That's ok though. I can still just use the other program by calling it and getting the data. No worries!
Big worries. If you decide to share the files, I’ll be around.
Here are the files. Attached also is the program I'm using to call using SHELL to get the correct data. I hope this gives you some clue as to why it happens. Also, I tried to see if I opened the mp3 file in my program and instead of immediately reading into the labels, I output the information into a text file and read it back. Still received the same garbled result. It only gives me a clear result when using a regular QB64 program.
I guess you might also want these so you won't have all those "Missing File" warnings in the program.
Also, apologies for not seeing your reply asking for my build of InForm. I'm using build 11.
songinfo.txt songinfo.txt Here are two examples. New mp3 file. The one with valid data came from the function written using a standard QB64 program. The second one with garbled text came from the InForm version.
I see where someone else from last year had a similar issue: https://github.com/FellippeHeitor/InForm/issues/97
Hi, I found the bug in your program. To fix it, you must add DIM position AS LONG
in SUB GetSongTags
.
The issue here is that your variable position
, which you were using to calculate where to start reading the tags in the MP3 file, was being defined as an INTEGER, which overflows at 32767. That didn't happen in the standalone version because there was no DEFINT A-Z
there (you used this in the InForm version for the code to get the Open Dialog) and the default data type in QB64 is SINGLE, which can go above the INTEGER limit.
Then, when position was an INTEGER and you attempted to set it to a value higher than 32767 (in this case, LOF(file) minus some arbitrary number), you'd end up overflowing and going negative, which created all sort of garbage by actually reading wave data from the MP3 file.
I appreciate the help. While what you told me fixed the issue it still doesn't explain why it would work for several times in the InForm version before stopping suddenly when I made no code changes in-between it working and it not working.
Thank you for looking into this, though.
You sure adding the Open Dialog code isn't what made the difference?
I made a little program for playing mp3 audio files. It displays album art as well as the metadata from the file displayed in the labels I made. It worked several times back to back but suddenly, after I compiled it once more, it stopped displaying the strings in the labels correctly. Below is the output as it shows when I make a standard QB64 program: The code for that output is: When I translate that code into a sub to use in InForm it looks like this: I don't know what happened or why it suddenly does not work anymore. I've reinstalled QB64 v1.3 and re-installed InForm. I installed QB64 v1.4 and still no luck. Do you have any idea why it would suddenly stop or how I could go about fixing it?