Demo Program I did for a radio engineer
I was contacted by a local radio station about developing an application to assist in creating their work scheduling sheets,
It seems that Microsoft screwed them all up. The previous versions of media player showed the duration of a song. This new one does not do that. This made it difficult as now they had to look up the data from other sources.
What is presented here is a demo to show I could do what they wanted.
It was also a chance for me to dig deeper into the new Windows Media Player. It is much clearer how it sets up and reports the open and play status as they occur.
Jack
Re: Demo Program I did for a radio engineer
Looks like the attachment didn;t go through. Don't have a clue as to why.
Re: Demo Program I did for a radio engineer
Quote:
Valid file extensions: 7z asa asmx asp aspx bas bmp bz2 c cls cpp cs ctl doc docx frm frx gif gz h hpp jpe jpeg jpg pdf php png psd rar res txt vb xlt xml zip
What type of file is your extension?
Re: Demo Program I did for a radio engineer
Quote:
Originally Posted by
Steve R Jones
What type of file is your extension?
It was a Zip file. It looked like it was sent, I never got any kind of error message.
I have no idea why it didn.t go.
Re: Demo Program I did for a radio engineer
Quote:
Originally Posted by
John Rizzo
It was a Zip file. It looked like it was sent, I never got any kind of error message.
I have no idea why it didn.t go.
Max-Size exceeded? Binaries inside?
as to your initial thing (Duration of mp3 for Radio Station):
https://stackoverflow.com/questions/...-ffmpeg-output
I would probably throw everything at ffprobe outputting it to a CSV
No need for any fancy program
Re: Demo Program I did for a radio engineer
With regard to the duration. There are calculations you can do to determine the length of the audio dependent upon audio type. You'd have to look up what other people have done in this regard but it ought to be possible to extrapolate the duration from the various types by searching online, you can then convert that to VB6. It relates to filesize and and the bitrate. I have done it myself for MP3/WAV types I think, if I can find the code I will dig it out and post it here. Don't hold your breath.
Re: Demo Program I did for a radio engineer
Windows natively supports duration for mp3 and wav since Windows 7 and many other audio types in 10. Just ask Windows:
[VB6, Vista+] A compact function to retrieve any property by name, locally formatted
Duration = GetPropertyDisplayString("C:\path\to\file.mp3", "System.Media.Duration")
Returns it already formatted in hh:mm:ss
Re: Demo Program I did for a radio engineer
Quote:
Originally Posted by
fafalone
Very nice, faf.
Kudos.
Re: Demo Program I did for a radio engineer
Quote:
Originally Posted by
fafalone
I was aware of that function, but from what I understand it puts quite a burden on the cpu and should only be use minimally.
I don't know if that is true or not, but it was trivial to grab and then computation was easy; divide by 60 then mod by 60. don't think there are many songs or commercials on the radio that exceed that.
Jack
Re: Demo Program I did for a radio engineer
It's a fairly heavyweight option yes; but I'm not sure how much time you can really save when in any case you'd still have to open the file and read it, since that's the slowest step; and how many files it would take reading at once for that difference to matter from a practical standpoint.
I'd bet the i/o is the bottleneck and unless Windows is reading the entire file first and another method could get it from the headers, there's not going to be a significant difference until files at once is into the 5 digits.
(The method from my post is also what Windows uses when you open a folder of MP3s in Explorer and the Duration column is used; so if that's not too slow, my code won't be either. Making the IPropertyDescription module level that's only done once would improve performance too.).
Re: Demo Program I did for a radio engineer
Quote:
Originally Posted by
fafalone
It's a fairly heavyweight option yes; but I'm not sure how much time you can really save when in any case you'd still have to open the file and read it, since that's the slowest step; and how many files it would take reading at once for that difference to matter from a practical standpoint.
I'd bet the i/o is the bottleneck and unless Windows is reading the entire file first and another method could get it from the headers, there's not going to be a significant difference until files at once is into the 5 digits.
(The method from my post is also what Windows uses when you open a folder of MP3s in Explorer and the Duration column is used; so if that's not too slow, my code won't be either. Making the IPropertyDescription module level that's only done once would improve performance too.).
I remember doing a proof-of-concept in FreePascal with the ffmpeg-libs some years ago.
IIRC, you could read out the Duration of any multimedia-file (Audio, Video) not from Metadata, but calculated on the fly by ffmpeg, involving frames per second, size of each frame (bitrate?), count of frames, and what not.
Don't remember exactly.
Though i do remember the result was near instantenous