[PATCH 1/3] Enable broken audio CD image support in cue stream driver
The cue stream driver is basically capable of supporting audio images, too, but didn't do so far due to some bugs. On the one hand it reported an audio sector size of 0 bytes, on the other hand it worked with fixed video CD sector data sizes. By making these sector information variable, it now handles audio images with demuxer rawaudio as well. Ingo
On Thu, 13 Aug 2015 21:47:07 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
The cue stream driver is basically capable of supporting audio images, too, but didn't do so far due to some bugs.
On the one hand it reported an audio sector size of 0 bytes, on the other hand it worked with fixed video CD sector data sizes.
By making these sector information variable, it now handles audio images with demuxer rawaudio as well.
nice. there are some bin/cue bugs on the tracker, if you want to take a look maybe? or possibly your patches fix it already... http://trac.mplayerhq.hu/ticket/1096 -compn
compn wrote on Thu, 13 Aug 2015 21:18:11 -0400:
On Thu, 13 Aug 2015 21:47:07 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
By making these sector information variable, it now handles audio images with demuxer rawaudio as well.
nice. there are some bin/cue bugs on the tracker, if you want to take a look maybe? or possibly your patches fix it already...
Unfortunately, it doesn't, because these reports refer to common audio formats like wav instead to bin images. The cue driver depends on the MSF addressing scheme, i.e. there must be a relation between the playback time and the position of data in the file holding the audio data. It would be necessary to introduce a second "addressing scheme" that is somehow based on the playback time itself, i.e. skip when seeking a track and EOF if playback duration has elapsed (*), in order to allow a cue file to be something like a playlist for whatever audio (or video) formats. (*) I currently don't know whether this is possible within the stream driver. Ingo
Le septidi 27 thermidor, an CCXXIII, Ingo Brückl a écrit :
Unfortunately, it doesn't, because these reports refer to common audio formats like wav instead to bin images.
I am not sure how the discussion arrived here, but I believe that for pure audio CD, "bin images" are just raw 16-bits stereo 44100 Hz PCM. Regards, -- Nicolas George
Nicolas George wrote on Fri, 14 Aug 2015 12:00:34 +0200:
Le septidi 27 thermidor, an CCXXIII, Ingo Brückl a écrit :
Unfortunately, it doesn't, because these reports refer to common audio formats like wav instead to bin images.
I am not sure how the discussion arrived here, but I believe that for pure audio CD, "bin images" are just raw 16-bits stereo 44100 Hz PCM.
Yes, that's why we can play these audio CD images with demuxer rawaudio when applying my patch, but people want to play other audio formats as well. The bug report compn was pointing to was about wav/cue. Ingo
On Fri, 14 Aug 2015 11:51:15 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
compn wrote on Thu, 13 Aug 2015 21:18:11 -0400:
On Thu, 13 Aug 2015 21:47:07 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
By making these sector information variable, it now handles audio images with demuxer rawaudio as well.
nice. there are some bin/cue bugs on the tracker, if you want to take a look maybe? or possibly your patches fix it already...
Unfortunately, it doesn't, because these reports refer to common audio formats like wav instead to bin images.
The cue driver depends on the MSF addressing scheme, i.e. there must be a relation between the playback time and the position of data in the file holding the audio data.
It would be necessary to introduce a second "addressing scheme" that is somehow based on the playback time itself, i.e. skip when seeking a track and EOF if playback duration has elapsed (*), in order to allow a cue file to be something like a playlist for whatever audio (or video) formats.
(*) I currently don't know whether this is possible within the stream driver.
oops. ok, yes i see that is like a cue sheet one would use to burn the cd. where our bin/cue support only handles whole-large files. i get it. individual files vs one big bin file. so this cue file would be more of a playlist file. all i can think of is dvd support that plays directories of individual .vob files. e.g. dvd:// -dvd-device /path/to/VIDEO_TS/ but that would probably take a lot of effort to code for cue/wav. easier to just do mplayer *.wav :P detect these cue files and modify playlist code to support them? too many security issues ? :\ thanks for answering my dumb question, ignore me! -compn
compn wrote on Fri, 14 Aug 2015 08:13:37 -0400:
detect these cue files and modify playlist code to support them? too many security issues ? :\
Even then mplayer would have to keep track of the time played for a playlist item in order to recognize the end of the track. And, the playlist would need a possibility to skip before playing (no skip for normal playlists), since we are handling tracks inside one big file. I doubt that this is acceptable for plain MPlayer, although I would take it into consideration for the GUI where playlists are handled more freely (since there is an explicit option to load a playlist). I guess this skipping and recognizing the end would be perfectly OK inside the cue stream driver (since it's completely transparent then), but the stream would need information and help from the demuxer in that case, and I currently have no idea whether it's possible or acceptable for a stream to access the demuxer. Ingo
participants (3)
-
compn -
Ingo Brückl -
Nicolas George