Forums Bug Reports $insong.length wrong with VBR

This was reported 5 years ago, but is still an issue so I wanted to bring it up again.

$insong.length does not display the correct song length if the MP3 is in VBR format. It usually displays a much longer length. It appears that only the length is affected and not the .pos . Now, mIRC can display the correct length already by using $sound($insong.fname).length , so everything is there to get the right length. It just needs to be changed for $insong.length so it uses the same method.

Although it's possible now to get the right length, it doesn't really make much sense to have an $insong.length if it's not going to work correctly.

The reason for this is that mIRC uses the Windows MCI functions to play sound files and unfortunately they return an incorrect length value for MP3s that use VBR. The $sound() identifier uses its own methods to determine the properties of an MP3 file.

The /splay command and the $inwave, $inmidi and $insong identifiers use the MCI functions to set and determine .pos and .length as Windows MCI sees them. So while I could change $insong.length to return the $sound().length result, it might not be usable with /splay (I haven't had a chance to test out how MCI would react in this situation).

If it isn't usable, then there's nothing more to be done. However, if it will work, I think it would be a good idea to make the change. Otherwise, why have those $in*.length identifiers if they are only right for some songs? If nothing else, the help file should mention that it won't work with VBR and recommend using $sound().length instead.

It's somewhat complex because $insong.pos and /splay with a specified position are also affected by this. I suppose it could also behave differently on different versions of Windows although I haven't tested this.

Once you start playing a VBR MP3, the $insong.pos will be accurate relative to the starting point. So for example, it will increment by exactly 1000 every second like it should. But suppose you attempt to start 30 seconds into a VBR MP3 with /splay filename.mp3 30000. It actually will start at some point before or after the true 30 second mark in the MP3 file (depending on where it estimated the position to be), but $insong.pos will report 30000 and, from that point onward, will increment by 1000 every second.

So there still is some usefulness to the $insong.length value, as it will tell you the largest value that /splay will accept for the "position" field. I think it is wise to leave $insong.length as is because of this.

Not sure how often you start out in the middle of a music file with /splay and then to use the .length to determine how what the largest number you can use for a starting parameter is, but your point is good. Anyhow, like I said, if it can't be fixed (and that would include fixing .pos), then it would be good to at least explain this in the help file so people aren't left wondering why the results are incorrect.

Perhaps, for the scenario you mention, a $in*.vbrlength option would be good. Either to be used to get the current $in*.length on songs or to get the $sound().length depending which would work best. I know having the two isn't really different than using $sound instead, but it at least provides accurate lengths for $in* as well as giving you the "wrong" vbr length necessary for your scenario.

I don't really know. Just a note in the help file might be fine, or some way to fix .pos and .length both so they are valid on all files. That would be best, but probably the most difficult.