MP3s

Colin Holgate colinholgate at gmail.com
Mon Apr 13 11:45:35 EDT 2020


I don’t know where it is now, probably lost, but I had a JVC quadraphonic 8 Track player. It could play regular 8 Track, which involved playing two tracks on the first loop and the other two tracks on the second loop, or it could play the four tracks in one loop. I only had a few tapes for it, one of those was a special recording of The Six Wives of Henry the Eighth, by Rick Wakeman.


> On Apr 13, 2020, at 9:40 AM, Richard Gaskin via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Graham Samuel wrote:
> 
> > Well, Richard, as usual you say something informative and useful!
> >
> > I didn’t know that LC could play a sound file in MP3 format.
> 
> LC's Player control uses the host OS's playback engine, so as long as the OS-supplied media player can handle a format, LC should be able to as well.
> 
> 
> > Instinctively I thought that an audioclip was the way to go, because I
> > saw it as a small chunk of data best embedded in my app. In my mind,
> > the format of an external file trades flexibility (the user or the app
> > can switch content easily) against a massive overhead of storage and
> > software mechanics and potential delays due to loading etc, whereas
> > the audioclip is small, clean, and can be started and stopped with no
> > overheads.
> 
> True, reading the media file takes a bit more time than a clip already in RAM with the rest of the stack file.  But in many cases it's not noticeable.  And where it is noticeable it probably has less to do with the file I/O than the codec itself:  HC's SND resources had few compression options, and MC's audioclips were limited to .au format, which IIRC isn't compressed at all.
> 
> It might be nice to see LC expand the internal clips options to support the same range of formats/codecs the Player does. But even then it would be limited to smaller files where it's practical to load them all into RAM with the rest of the stack file, modestly useful for some projects but prohibitive with longer files.
> 
> As for user modification, the files can be in the Mac bundle, and on Windows usually an installer is required anyway so you can put them in any useful place the user is unlikely to stumble across them accidentally (this isn't a problem at all on Linix - the absence of a functional Player in that LC version simplifies many things <g>).
> 
> I miss the simplicity of delivering true stand-alone apps, but with so many of the most lauded features of LC 8-and-later having been implemented as externals, adding some media files to the mix doesn't affect deployment options much.
> 
> If there's a security or other concern requiring the files be protected from user manipulation, there are options for that.  Like any DRM, there's usually a tradeoff between strength and ease of implementation, but if it's needed we can explore it.
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list