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@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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
