read this application in its most general form . this includes , without limitation : references to specific structures or techniques include alternative or more general structures or techniques , especially when discussing aspects of the invention , or how the invention might be made or used . references to “ preferred ” structures or techniques generally mean that the inventor contemplates using those structures are techniques , and think they are best for the intended application . this does not exclude other structures or techniques for the invention , and does not mean that the preferred structures or techniques would necessarily be preferred in all circumstances . references to first contemplated causes or effects for some implementations do not preclude other causes or effects that might occur in other implementations , even if completely contrary , where circumstances would indicate that the first contemplated causes or effects would not be as determinative of the structures or techniques to be selected for actual use . references to first reasons for using particular structures or techniques do not preclude other reasons or other structures or techniques , even if completely contrary , where circumstances would indicate that the first structures or techniques are not as compelling . the invention includes those other reasons or other structures or techniques , especially where circumstances would indicate they would achieve the same effect or purpose as the first reasons , structures , or techniques . read this application with the following terms and phrases in their most general form . the general meaning of each of these terms or phrases is illustrative , not in any way limiting . the term “ format ” generally refers to any encoding technique by which media , whether audio or visual or otherwise , that can be sensed by a human being , is maintained in a digital format that can be sensed by a computing device . the phrase “ data compression ” generally refers to techniques in which media , whether audio or visual or otherwise , that can be sensed by a human being , is maintained in and otherwise - limited amount of storage . as described herein , in general , a greater degree of data compression involves a lesser degree of precision or fidelity to the original digital media , and vice versa . the terms “ fidelity ” and “ precision ” generally refer to the degree of accuracy with respect to a set of original digital media , that a particular set of data in a digital format is faithful to the original sensation of that original digital media by a human being . fig . 1 shows a block diagram of a system according to this application ; and fig2 shows a conceptual view of a process flow in a method according to this application . a fig1 shows a block diagram of a system according to this application . a system 100 includes elements as shown in the fig1 , including at least : as described below in this application in other and further detail , the information processing device 110 operates to perform computations and other methods steps as might be necessary or convenient to achieve the purposes described in this application . in general , those purposes include maintaining that media stream 120 in an accessible format in memory or mass storage , decoding information associated with that media stream 120 and presenting and media stream 120 to the user 170 ( described below ), responding to those control and display elements 130 , and using the control and display elements 130 to present that media stream 120 to the user 170 . the information - processing device 110 includes elements as shown in the fig1 , including at least : 111 a computing device , including a processor , program and data memory , and mass storage 112 a set of software elements 113 a communication link 114 one or more external devices ( not strictly part of the information - processing device ) in operation of the computing device 111 , the processor operates under control of instructions maintained in the program memory and the mass storage . the processor operates on the software elements 112 . the data memory and mass storage maintain the software elements 112 in storage and for manipulation by the processor . instructions interpret rule by the processor , as well as the media stream 120 , might be maintained in the data memory or mass storage 111 . the communication link 113 couples the information - processing device 110 , including the computing device 111 and the software elements 112 , to the one or more external devices 114 . the communication link 113 might include any form of communication pathway , such as for example , a network , an internal communications path in a computing device , or otherwise . as described below , the media stream 120 might come from an audio file 121 , such as maintained in data memory or mass storage , or might come from a the processor 111 , operating under control of application program code 122 . in either case , the media stream 120 includes digital information , as described below , which is encoded by the processor 111 , operating under control of an encoder , and decoded by the processor 111 , operating under control of a decoder . the decoded form is available for presentation , by the processor 111 , to the user 170 . the set of control and display elements 130 includes elements as shown in the fig1 , including at least : 131 a set of control elements disposed for allowing one or more users 170 to set or modify media parameters , select media to be presented , or otherwise control the information - processing system 100 132 a set of presentation elements disposed for allowing one or more users 170 to receive media presentations , such as for example a monitor and a set of speakers 133 a set of input / output elements disposed for allowing one or more users 170 to exchange and record data with the system 100 in cases which those data are either ( 1 ) exchanged in bulk , or ( 2 ) disposed on a physical medium 134 as described herein , the one or more users 170 ( disposed either locally to the system 100 or otherwise ) might control the system 100 using the control elements 131 . the one or more users 170 might receive presentations of media from the presentation elements 132 . the one or more users 170 might import or export media in bulk , or might import or export instructions for performing the process steps described in this application , including exchanging that media or those instructions with media or instructions dispose on the physical medium 134 . the set of software elements 112 includes elements as shown in the fig1 , including at least : the media information 140 includes elements as shown in the fig1 , including at least : 141 a set of audio input data , as well as a first set of presentable audio data 141 a decoded and re - encoded from that audio input data 141 in a first format , and a second set of presentable audio data 141 b decoded and re - encoded from that audio input data 141 in a second format 142 a set of processed already - played audio data 143 a current read head position pointer , sometimes referred to herein as the “ read head ”, possibly referencing either a first position 143 a or a second position 143 b , and possibly referencing a switch reference time 143 c 144 a set of extra presentable audio data to be discarded , sometimes referred to herein as a set of “ limbo frames ” as described below in this application in other and further detail , the media information 140 includes the audio input data 141 and a set of already - played audio data 142 , the former representing both past audio data already decoded and presented to the user 170 and future audio data yet to be decoded and presented to the user 170 , and the latter representing past audio data already decoded and presented to the user 170 . as described below , live preview of different encoding formats for the media stream 120 might have the effect that some amount of audio input data 141 might have to be decoded a second time , or alternatively , some amount of the already - played audio data 142 might have to be discarded , to allow the user 170 a smooth presentation of the media stream 120 when switching encoding formats . the set of instruction threads 150 includes elements as shown in the fig1 , including at least : as described below in this application in other and further detail , the processor 111 operates under control of instructions , as maintained in the program memory , to perform process steps for the input thread 151 and to perform process steps for the playback thread 152 . as described below , the input thread 151 receives the set of audio input data 141 , and performs the ( relatively more difficult ) tasks of encoding that audio input data 141 for presentation to the user 170 , using an encoder for a selected format , and from a result of encoding that audio input data 141 , i . e ., a set of encoded data capable of being presented to the user 170 , applies a decoder for that same selected format . the playback thread 152 receives a result of decoding that audio input data 141 , i . e ., a set of presentable audio data , and presents that presentable audio data to the user 170 . as described below , a distinction is made between the input thread 151 and the playback thread 152 , because it may occur that more than one input thread 151 is concurrently operational , with the effect that more than one set of audio data are available for use by the playback thread 152 . the set of data buffers and pointers 160 includes elements as shown in the fig1 , including at least a double - buffered ring buffer , including a first ring buffer 160 a and a second ring buffer 160 b . as described below in this application in other and further detail , one aspect of maintaining a smooth transition when the user 170 desires live preview of the media stream 120 in a different format is that it might be necessary or convenient to re - encode some amount of the audio input data 141 . a location in a stream representing the audio input data 141 is described by the current read head position pointer 143 . similarly , as that audio input data 141 is encoded into encoded data and decoded into presentable audio data by one of the input threads 151 , presentable audio data is deposited into the ring buffer 160 , where it is maintained for reading and presentation by the playback thread 152 . in the context of the invention , there is no particular requirement that the ring buffer 160 take any particular form , and there is no reason to limit the ring buffer 160 , or the invention , in this regard . as described below , one aspect of maintaining a smooth transition when the user 170 desires live preview of the media stream 120 in a different format is that presentable audio data will generally be read ( and consumed ) by the playback thread 152 , while new presentable audio data will generally be written by the input thread 151 . during the course of a transition between encoding formats , presentable audio data is written by a first input thread 151 into a first portion of the ring buffer 160 , such as 160 a , even though such presentable audio data might have already been written by a second input thread 151 into a second portion of the ring buffer 160 , such as 160 b . the playback thread 152 reads a sufficient amount of presentable audio data from the second portion of the ring buffer 143 , until the time comes to start reading presentable audio data from the first portion of the ring buffer 160 . this has the effect that the first portion and the second portion of the ring buffer 160 aid in providing a double - buffering technique for the transition between encoding formats . as described below , when the user 170 desires live preview of the media stream 120 in a different format , it might occur that some amount of presentable audio data has been generated by the second input thread 151 and written into the second ring buffer 160 , even though that presentable audio data is to be discarded without being read by the playback thread 152 . that amount of presentable audio data is sometimes referred to herein as a set of “ limbo frames ” 144 . a fig2 shows a conceptual view of a process flow in a method according to this application . a method 200 includes flow markers and process steps as shown in the fig2 , including at least : the steps following each of the flow markers might be performed concurrently , in parallel , pipelined , or otherwise using multiple computing devices , or within a single computing device with multiple cores , threads , processes or processors , with the steps following a first flow marker being performed a first set of data while the steps following a second flow marker being performed a second set of data . a flow marker 200 a indicates a beginning for the method 200 . at a step 201 , the method 200 causes the processor 111 to begin operating in the context of the input thread 151 at the flow marker 210 , and to begin operating in the context of the playback thread 152 at the flow marker 220 . reaching a flow marker 210 indicates that the method 200 is ready to process audio input data 141 . at a step 211 , the processor 111 , operating in the context of the input thread 151 , receives the audio input data 141 . at a step 212 , the processor 111 , operating in the context of the input thread 151 , processes the audio input data 141 and generates a set of encoded audio data . at a step 213 , the processor 111 , operating in the context of the input thread 151 , processes the encoded audio data and generates a set of presentable audio data . at a step 214 , the processor 111 , operating in the context of the input thread 151 , places the presentable audio data one of the two ring buffers 160 . the processor 111 , operating in the context of the input thread 151 , continues with the flow marker 210 . this has the effect that the processor 111 , operating in the context of the input thread 151 , repeats the step 211 , the step 212 , and the step 213 , until the user 170 directs otherwise or until the processor 111 reaches the end of the audio input data 141 . the user 170 might direct the processor 111 to stop processing the audio input data 141 , or to process the audio input data 141 using a different encoding format . in those cases in which the processor 111 reaches the end of the audio input data 141 , and those cases in which the user 170 directs the processor 111 to stop processing , the method 200 continues with the flow marker 200 b , where the method 200 ends . reaching a flow marker 220 indicates that the method 200 is ready to playback frames of presentable audio data . at a step 221 , the processor 111 , operating in the context of the playback thread 152 , receives the presentable audio data from one of the two ring buffers 160 . at a step 222 , the processor 111 , operating in the context of the playback thread 152 , processes the presentable audio data from one of the two ring buffers 160 . at a step 223 , the processor 111 , operating in the context of the playback thread 152 , presents the presentable audio data to the user 170 . in one embodiment , the presentable audio data are presented to the user 170 in the form of playing sound equivalent to that data using speakers , i . e ., the presentation elements 132 . although this application describes in greater detail those embodiments in which the media stream 120 is an audio sequence and data representing that stream represents audio data , in the context of the invention , there is no particular reason by the media stream 120 or the invention should be limited in that regard . in alternative embodiments , the media stream 120 might include audio - visual data , still or moving visual data , animation , or any other information capable of being presented to a user 170 . at a step 224 , the method 200 determines when the user 170 has instructed a change in encoding format , such as while the processor 111 is presenting the presentable audio data . in response to that determination , the method proceeds with the flow marker 230 . reaching a flow marker 230 indicates that the method 200 is ready to change encoding formats . at a step 231 , the method 200 , having determined when the user 170 has instructed a change in encoding format , determines whether the media data 120 is being read from an audio file 121 or from an application process 122 . if the media data 120 is being read from an audio file 121 , the method 200 proceeds with the step 232 . if the media data 120 is being read from an application process 122 , the method 200 proceeds with the flow marker 240 . at a step 232 , the method 200 determines how far ahead the input thread 151 has decoded the audio file 121 , as opposed to the playback thread 152 . as the playback thread 152 receives and processes presentable audio data from the input thread 151 , the playback thread 152 will always be at least a small amount of time behind the input thread 151 . at a step 233 , the method 200 moves the read head 143 “ back in time ” from a first position 143 a reached by the input thread 151 to a second position 143 b reached by the playback thread 152 . this step might leave some set of “ limbo frames ” 144 left over for removal . at a step 234 , the processor , operating under control of the input thread 151 , reads from the audio file 121 starting at the new position 143 b of the read head 143 , and generates presentable audio data . at a step 235 , the processor , operating under control of the playback thread 152 , receives the presentable audio data from the input thread 151 , and continues presenting the media stream 120 to the user 170 . after reading this application , those skilled in the art will note that the input thread 151 takes at least a finite amount of time dt to start generating presentable audio data for use by the playback thread 152 . this has the effect that it takes at least that same finite amount of time dt before the changeover can occur in response to the user 170 . the playback thread 152 uses just that amount of time dt to present frames that were encoded and re - decoded using the earlier encoding method , switching over when frames are ready that are encoded and re - decoded using the new encoding method . if there are any additional frames left in the ring buffer 160 after the switchover by the playback thread 152 , i . e ., limbo frames 144 , they are discarded . after reading this application , those skilled in the art will note that these limbo frames 144 are for just the amount of time the read head 143 was moved “ back in time ” in the earlier step 233 , minus the amount of time dt . the method 200 continues at the flow marker 200 b , where the method 200 ends . reaching a flow marker 230 indicates that the method 200 is ready to change encoding formats for the output of an application process 122 . at a step 241 , the method 200 determines how far the input thread 151 has encoded and decoded the audio file 121 , as shown by a first position 143 a of the read head 143 . at a step 242 , the processor 111 , operating under control of the input thread 151 , reads from the application process 122 starting at the same first position 143 a of the read head 143 , and generates new presentable audio data encoded and re - decoded in the second format . this new set of presentable audio data is placed in the alternate half of the ring buffer 160 , with the effect that encoded frames from the input thread 151 are double - buffered for use by the playback thread 152 , presentable audio data responsive to the first format going into the first half and presentable audio data responsive to the second format going into the second half . at a step 243 , the processor 111 , operating under control of the playback thread 152 , continues reading from the ring buffer 160 while the input thread 151 is generating presentable audio data responsive to the second audio format . at a step 244 , the method 200 determines that presentable audio data responsive to the second audio format is available in the ring buffer 160 for the playback thread 152 to present . the method 200 causes the processor 111 , operating under control of the playback thread 152 , to read presentable audio data from the second portion of the ring buffer 160 , thus presenting audio data responsive to the second format seamlessly and without noticeable transition from the first format . this occurs at a second position 143 b for the read head 143 . at a step 245 , as the input thread 151 is writing presentable audio data responsive to the second format to the second half of the ring buffer 160 , and the playback thread 152 is reading that presentable audio data responsive to the second format from the second half of the ring buffer 160 , there is no particular need to retain any of the “ extra ” presentable audio data 144 responsive to the first format that was placed in the first half of the ring buffer 160 . accordingly , the method discards that “ extra ” presentable audio data 144 . after reading this application , those skilled in the art will recognize that the amount of “ extra ” presentable audio data 144 is responsive to the finite amount of time dt needed for the input thread 151 to start generating presentable audio data , for use by the playback thread 152 , responsive to a new encoding - decoding format . thus , at a switch reference time 143 c ( when the user 170 requests a change in format ), the playback thread 152 should be reading from a first position 143 a of the presentable audio data , in a first portion of the ring buffer 160 . thereafter , the format change will take that finite amount of time dt needed for the input thread 151 to start generating presentable audio data , completing at a second position 143 b of the audio input data 141 . at that time , the playback thread 152 will be able to read presentable audio data from a second portion of the ring buffer 160 . any extra presentable audio data 144 remaining in the first portion of the ring buffer 160 can be discarded . reaching a flow marker 200 b indicates an end of the method 200 . after reading this application , those skilled in the art will recognize that the invention has wide applicability , and is not limited to the embodiments described herein .