Converting .cue sheet to something understood by PM123
Ilya Zakharevich
sheets. E.g.,
*) I have a pair of .ape and .cue files
*) It loads .ape file fine;
*) It shows an error when loading .cue file.
As a result, it plays .ape file without breaking it into sub-chunks
(and has no meta-info for the file/chunks).
Fine. But on the other hand, essentially, .cue file is just a
playlist mentioning sub-chunks of another audio file. And PM123
claims supporting sub-chunks, and recursive playlist. So,
theoretically, it should not be a big deal to convert .cue file to
some flavor of playlist which is understood by PM123.
Do people have such (or similar) converters? (I see that .inf file
contains the docs about the format, and I see no place to put
metainfo... Any idea?)
Thanks,
Ilya
Marcel Müller
Ilya Zakharevich wrote:
> I try PM123 v1.40-a3, and it looks like it does not understand cue
> sheets. E.g.,
>
> *) I have a pair of .ape and .cue files
> *) It loads .ape file fine;
> *) It shows an error when loading .cue file.
.cue is currently unsupported. It is on the todo list. See
http://www.maazl.de/project/pm123/index.html
But a reasonable solution requires an improved decoder plug-in interface
that supports playlist like objects too.
> Fine. But on the other hand, essentially, .cue file is just a
> playlist mentioning sub-chunks of another audio file. And PM123
> claims supporting sub-chunks, and recursive playlist. So,
> theoretically, it should not be a big deal to convert .cue file to
> some flavor of playlist which is understood by PM123.
True. A REXX script could convert a .cue file to a .lst file containing
different sub-chunks of the same physical file. The format description
is part of the PM123 help file. However, I strongly recommend to update
to 1.40a4 because several bugs have been fixed concerning location
specifiers.
> Do people have such (or similar) converters? (I see that .inf file
> contains the docs about the format, and I see no place to put
> metainfo... Any idea?)
There is no solution for the metainfos so far, since metainfos are
properties of the Song, which is in fact always the same file. There
is no way to override this properties from a playlist reference. This
would require several changes to the PM123 core engine.
Marcel
Ilya Zakharevich
>> Fine. But on the other hand, essentially, .cue file is just a
>> playlist mentioning sub-chunks of another audio file. And PM123
>> claims supporting sub-chunks, and recursive playlist. So,
>> theoretically, it should not be a big deal to convert .cue file to
>> some flavor of playlist which is understood by PM123.
I tried it. The documented syntax does not work in a3. Finally, I
managed to understand how to edit playlists by hand (undocumented; one
needs Alt-Click!) and requested only-a-chunk. The saved file has
undocumented syntax (START/END).
Anyway, all this is fully academic with a3, since chunk requests are
just ignored - both after manual editing, and from saved playlist...
[I add start/stop fields to a playlist entry, then `load' the entry
- and ALL the file is played anyway.]
> True. A REXX script could convert a .cue file to a .lst file containing
> different sub-chunks of the same physical file. The format description
> is part of the PM123 help file. However, I strongly recommend to update
> to 1.40a4 because several bugs have been fixed concerning location
> specifiers.
I see many bugs with a3. Is chunk-semantic working with a4?
>> Do people have such (or similar) converters? (I see that .inf file
>> contains the docs about the format, and I see no place to put
>> metainfo... Any idea?)
> There is no solution for the metainfos so far, since metainfos are
> properties of the Song, which is in fact always the same file.
> There is no way to override this properties from a playlist
> reference. This would require several changes to the PM123 core
> engine.
I hope not too many changes - just have an extra place to store metainfo,
and choose whatever is present for a particular field... Reset the
second place whenever position in playlist is changing...
Anyway, since pm123 has such a limited UI, setting metainfo is not a
very important request (as far as ALIAS is shown). (It is a major
pity that z! can't play flac and ape...)
[Or did I miss something in the docs, and THERE IS a way to
automatically show metainfo?]
Thnaks,
Ilya
Marcel Müller
> On 2009-02-28, Marcel Müller <news.5...@spamgourmet.org> wrote:
>>> Fine. But on the other hand, essentially, .cue file is just a
>>> playlist mentioning sub-chunks of another audio file. And PM123
>>> claims supporting sub-chunks, and recursive playlist. So,
>>> theoretically, it should not be a big deal to convert .cue file to
>>> some flavor of playlist which is understood by PM123.
>
> I tried it. The documented syntax does not work in a3. Finally, I
> managed to understand how to edit playlists by hand (undocumented; one
> needs Alt-Click!) and requested only-a-chunk.
The direct manipulation is now documented in a4.
It is likely that a properties dialog for playlist entries will come.
> The saved file has
> undocumented syntax (START/END).
The documentation of a3 was not recent.
> Anyway, all this is fully academic with a3, since chunk requests are
> just ignored - both after manual editing, and from saved playlist...
They only worked under certain circumstances, because most of the
decoders ignore the starting position field. And there were bugs in the
location syntax parser too, which caused the location pointers to fail
to deserialize in some cases.
> I see many bugs with a3. Is chunk-semantic working with a4?
I did not really test this so far. But at least the start positions
should work, because PM123 uses the same thing to store the current
playing position at exit or to start in the middle of a song. If a
decoder seems not to support the starting position, a4 sends a seek
command after receiving the first samples as work-around.
>> There is no way to override this properties from a playlist
>> reference. This would require several changes to the PM123 core
>> engine.
>
> I hope not too many changes - just have an extra place to store metainfo,
> and choose whatever is present for a particular field... Reset the
> second place whenever position in playlist is changing...
This is not that easy. First of all, the reference in the playlist is
another object type than the song and they have no common interface
(maybe this is a bad design). And most functions that deal with meta
infos take a pointer to a song rather than a pointer to a song reference
in the playlist. So they do not know about the origin of the reference.
Sometimes there may be no such reference at all, because you currently
loaded only a single song.
Secondly the core engine is normally some seconds ahead. So the meta
info change has to be delayed until the last sample of the previous song
has been played by the audio device. I think this is the less
complicated part, because other infos are delayed too.
> Anyway, since pm123 has such a limited UI, setting metainfo is not a
> very important request (as far as ALIAS is shown).
a3 did not show the alias in the player window. a4 does, but only if you
are in object name display mode.
> (It is a major
> pity that z! can't play flac and ape...)
Flac is broken in PM123 too. Because of an integer overflow in a
temporary expression seek operations are likely to fail. I know where
the bug is, but I can't compile the plug-in because of library dependencies.
> [Or did I miss something in the docs, and THERE IS a way to
> automatically show metainfo?]
Not beyond the scoller in the PM123 window.
There was a mode where the info dialog followed the current song. But
this caused problems and was removed.
Marcel
Ilya Zakharevich
>> Anyway, all this is fully academic with a3, since chunk requests are
>> just ignored - both after manual editing, and from saved playlist...
> They only worked under certain circumstances, because most of the
> decoders ignore the starting position field.
Why do they need to support it? Can't pm123 seek? .ape decoder can
seek without any problem... (Now I see a remark below...)
>> I see many bugs with a3. Is chunk-semantic working with a4?
> I did not really test this so far. But at least the start positions
> should work, because PM123 uses the same thing to store the current
> playing position at exit or to start in the middle of a song.
With a3, saving-on-exit does not work with APE... When I restart,
"nothing happens". I need to click ">" (Play) 3 (sic!) times, then it
start playing - but from the start...
> If a
> decoder seems not to support the starting position, a4 sends a seek
> command after receiving the first samples as work-around.
Aha! Thanks!
>> I hope not too many changes - just have an extra place to store metainfo,
>> and choose whatever is present for a particular field... Reset the
>> second place whenever position in playlist is changing...
> This is not that easy. First of all, the reference in the playlist is
> another object type than the song and they have no common interface
> (maybe this is a bad design).
I do not see it as a problem. So there are 2 different APIs - so what?
> And most functions that deal with meta
> infos take a pointer to a song rather than a pointer to a song reference
> in the playlist.
I would give them a reference to a "pseudo-song" object; it must have
the same API as a song object, but stores references to the song and
to the playlist entry. On calls, it consults both a song and playlist...
>> Anyway, since pm123 has such a limited UI, setting metainfo is not a
>> very important request (as far as ALIAS is shown).
> a3 did not show the alias in the player window. a4 does, but only if you
> are in object name display mode.
>> (It is a major pity that z! can't play flac and ape...)
> Flac is broken in PM123 too. Because of an integer overflow in a
> temporary expression seek operations are likely to fail. I know where
> the bug is, but I can't compile the plug-in because of library dependencies.
My compiles of FLAC are EMX; you need Innoteked one, right?
Was there a version of pm123 which works with flac? The only
alternative I have only primitive command-line playing without seeking
and any feedback... Hmm, I did not try MPlayer yet...
>> [Or did I miss something in the docs, and THERE IS a way to
>> automatically show metainfo?]
> Not beyond the scoller in the PM123 window.
> There was a mode where the info dialog followed the current song. But
> this caused problems and was removed.
Pity. Then 123 would be just a fallback for the cases when Z!
fails...
Thanks,
Ilya
Ilya Zakharevich
>> managed to understand how to edit playlists by hand (undocumented; one
>> needs Alt-Click!) and requested only-a-chunk.
> The direct manipulation is now documented in a4.
> It is likely that a properties dialog for playlist entries will come.
Well,
*) a4 does not recognize chunk syntax as saved by a3...
*) Entering start/end time 10.0/15.0 in the playlist editor lives some
trailing garbage after decimal dot...
*) The start time is granted when playing .ape (thanks!).
*) The end time is not. :-(
*) Loading a4 after exiting playing a file takes eternity (about 1e10
cycles). (I have 4 extra decoders loaded.)
*) Remembering last position with .ape kinda works: at start, counter
is at correct position; when I press "Play" it goes to 0, then back
to the remembered position.
*) Playlist editor still ships unusably narrow, and does not remember
the size of "the previous time it was resized".
*) I got SYS0147 exiting a4 after loading a slightly customized skin,
doing minimal edit to the skin, then loading it again).
Hmm, now I get on any exit - do not even need to play anything...
*) In the default.skn file, would not be it wiser to remove "Neat,
isn't it?" :-(
*) In the default.skn file, could one add instructions on how to
customize it: e.g.,
; to change colors in visualizer, make a copy this file, uncomment the
; following directive, and change the name of the color file appropriately
; 1=visplug/analyzer.dll,31,49,96,32,viscolor.txt
(the crucial part is the coordinates; I'm just guessing - please
change them to the correct ones). Shipping viscolor.txt with the
default settings would be nice too.
*) The default colors in the visualizer have very little contrast in
the "quiet music" part. I must have changed them to
SPECTROSCOPE-0=40,40,40
SPECTROSCOPE-4=0,0,200
SPECTROSCOPE-8=0,200,0
SPECTROSCOPE-16=180,0,0
SPECTROSCOPE-24=255,0,0
SPECTROSCOPE-40=255,255,0
SPECTROSCOPE-55=128,255,255
SPECTROSCOPE-63=255,255,255
Thanks,
Ilya
Marcel Müller
Ilya Zakharevich wrote:
> On 2009-03-01, Marcel Müller <news.5...@spamgourmet.com> wrote:
>>> I tried it. The documented syntax does not work in a3. Finally, I
>>> managed to understand how to edit playlists by hand (undocumented; one
>>> needs Alt-Click!) and requested only-a-chunk.
>
>> The direct manipulation is now documented in a4.
>> It is likely that a properties dialog for playlist entries will come.
>
> Well,
>
> *) a4 does not recognize chunk syntax as saved by a3...
Maybe. This is never tested.
> *) Entering start/end time 10.0/15.0 in the playlist editor lives some
> trailing garbage after decimal dot...
Entering where? The syntax start/end is not used anymore.
> *) The start time is granted when playing .ape (thanks!).
>
> *) The end time is not. :-(
Hm, a bug while comparing locations I guess.
> *) Loading a4 after exiting playing a file takes eternity (about 1e10
> cycles). (I have 4 extra decoders loaded.)
? - This is a good time to capture a log from the debug build.
> *) Remembering last position with .ape kinda works: at start, counter
> is at correct position; when I press "Play" it goes to 0, then back
> to the remembered position.
Well, this is a known problem. I did not manage to fix this so far.
> *) Playlist editor still ships unusably narrow, and does not remember
> the size of "the previous time it was resized".
I am currently unsure how to save window locations, since there is no
longer a single playlist. Either all of them have the same size or you
have to resize each one. Additionally the latter method would blow up
the ini file.
> *) I got SYS0147 exiting a4 after loading a slightly customized skin,
> doing minimal edit to the skin, then loading it again).
>
> Hmm, now I get on any exit - do not even need to play anything...
Probably a bug in the skin engine. Maybe an image resource is freed
twice. Again a log would be helpful.
> *) In the default.skn file, would not be it wiser to remove "Neat,
> isn't it?" :-(
I never changed that. It is from 1.32.
> *) In the default.skn file, could one add instructions on how to
> customize it: e.g.,
>
> ; to change colors in visualizer, make a copy this file, uncomment the
> ; following directive, and change the name of the color file appropriately
>
> ; 1=visplug/analyzer.dll,31,49,96,32,viscolor.txt
>
> (the crucial part is the coordinates; I'm just guessing - please
> change them to the correct ones). Shipping viscolor.txt with the
> default settings would be nice too.
The documentation of the analyzer contains the default values.
Of course, it could also be in a file too.
> *) The default colors in the visualizer have very little contrast in
> the "quiet music" part. I must have changed them to
>
> SPECTROSCOPE-0=40,40,40
> SPECTROSCOPE-4=0,0,200
> SPECTROSCOPE-8=0,200,0
> SPECTROSCOPE-16=180,0,0
> SPECTROSCOPE-24=255,0,0
> SPECTROSCOPE-40=255,255,0
> SPECTROSCOPE-55=128,255,255
> SPECTROSCOPE-63=255,255,255
This depends on the Gamma value of your display device. Most probably it
shows all color values below 128 very dark.
Marcel
Ilya Zakharevich
>> *) Entering start/end time 10.0/15.0 in the playlist editor lives some
>> trailing garbage after decimal dot...
>
> Entering where?
As I said: in the playlist editor. Alt-Click on the cell(s), enter
time, press Gray-Enter. Garbage appears.
>> *) Playlist editor still ships unusably narrow, and does not remember
>> the size of "the previous time it was resized".
> I am currently unsure how to save window locations, since there is no
> longer a single playlist. Either all of them have the same size or you
> have to resize each one. Additionally the latter method would blow up
> the ini file.
I would prefer all of them having the same size...
>> ; 1=visplug/analyzer.dll,31,49,96,32,viscolor.txt
>>
>> (the crucial part is the coordinates; I'm just guessing - please
>> change them to the correct ones). Shipping viscolor.txt with the
>> default settings would be nice too.
> The documentation of the analyzer contains the default values.
Can't find them in .inf file... So, what are the correct values?
> Of course, it could also be in a file too.
That would be nice, thanks...
>> *) The default colors in the visualizer have very little contrast in
>> the "quiet music" part. I must have changed them to
>>
>> SPECTROSCOPE-0=40,40,40
>> SPECTROSCOPE-4=0,0,200
>> SPECTROSCOPE-8=0,200,0
>> SPECTROSCOPE-16=180,0,0
>> SPECTROSCOPE-24=255,0,0
>> SPECTROSCOPE-40=255,255,0
>> SPECTROSCOPE-55=128,255,255
>> SPECTROSCOPE-63=255,255,255
>
> This depends on the Gamma value of your display device. Most probably it
> shows all color values below 128 very dark.
My gamma is 2.2, as expected (calibrated a week ago). The display is set
above 500nit, so the darks are in fact very bright... E.g, there is no
big deal in distinguishing 0,0,0 from 2,2,2 (at least in "stationary"
images ;-)...
Hope this helps,
Ilya
Marcel Müller
> On 2009-03-01, Marcel Müller <news.5...@spamgourmet.com> wrote:
>>> *) Entering start/end time 10.0/15.0 in the playlist editor lives some
>>> trailing garbage after decimal dot...
>> Entering where?
>
> As I said: in the playlist editor. Alt-Click on the cell(s), enter
> time, press Gray-Enter. Garbage appears.
Ah, OK, I see. If there are no fractional seconds, the output is broken.
- Fixed. Homepage is updated.
Also the stop location is working here as expected.
>>> *) Playlist editor still ships unusably narrow, and does not remember
>>> the size of "the previous time it was resized".
>
>> I am currently unsure how to save window locations, since there is no
>> longer a single playlist. Either all of them have the same size or you
>> have to resize each one. Additionally the latter method would blow up
>> the ini file.
>
> I would prefer all of them having the same size...
Could be helpful, if I let the PM chose the position.
>>> ; 1=visplug/analyzer.dll,31,49,96,32,viscolor.txt
>>>
>>> (the crucial part is the coordinates; I'm just guessing - please
>>> change them to the correct ones). Shipping viscolor.txt with the
>>> default settings would be nice too.
>
>> The documentation of the analyzer contains the default values.
>
> Can't find them in .inf file... So, what are the correct values?
You will find it as subpage of the analyzer's page under plug-ins.
http://www.maazl.de/project/pm123/manual/analyzerformat.html
>> This depends on the Gamma value of your display device. Most probably it
>> shows all color values below 128 very dark.
>
> My gamma is 2.2, as expected (calibrated a week ago). The display is set
> above 500nit, so the darks are in fact very bright... E.g, there is no
> big deal in distinguishing 0,0,0 from 2,2,2 (at least in "stationary"
> images ;-)...
Hmm, no idea. The default colors use values around 128 for the dark parts.
Marcel
Ilya Zakharevich
>>>> ; 1=visplug/analyzer.dll,31,49,96,32,viscolor.txt
>>>>
>>>> (the crucial part is the coordinates; I'm just guessing - please
>>>> change them to the correct ones). Shipping viscolor.txt with the
>>>> default settings would be nice too.
>>> The documentation of the analyzer contains the default values.
>> Can't find them in .inf file... So, what are the correct values?
> You will find it as subpage of the analyzer's page under plug-ins.
> http://www.maazl.de/project/pm123/manual/analyzerformat.html
No, I cannot find them there. So: what should one REALLY use instead
of 31,49,96,32 I used above?
>>> This depends on the Gamma value of your display device. Most probably it
>>> shows all color values below 128 very dark.
>> My gamma is 2.2, as expected (calibrated a week ago). The display is set
>> above 500nit, so the darks are in fact very bright... E.g, there is no
>> big deal in distinguishing 0,0,0 from 2,2,2 (at least in "stationary"
>> images ;-)...
> Hmm, no idea. The default colors use values around 128 for the dark parts.
No, they use values about 0,0,0 for the dark parts. E.g., level=1 is
mapped to 0,0,4 - which would quite impossible to distinguish from 0,0,0.
Thanks,
Ilya
Marcel Müller
> On 2009-03-02, Marcel Müller <news.5...@spamgourmet.com> wrote:
>>>> The documentation of the analyzer contains the default values.
>
>>> Can't find them in .inf file... So, what are the correct values?
>
>> You will find it as subpage of the analyzer's page under plug-ins.
>> http://www.maazl.de/project/pm123/manual/analyzerformat.html
>
> No, I cannot find them there. So: what should one REALLY use instead
> of 31,49,96,32 I used above?
Sorry, I thought you are talking about the colors.
The default coordinates are 32, 49, 95, 30 for the default skin.
I don't know why they changed a few pixels. I think this is a change
from PM123 1.32.
I will include these values in the documentation.
>>>> This depends on the Gamma value of your display device. Most probably it
>>>> shows all color values below 128 very dark.
>
>>> My gamma is 2.2, as expected (calibrated a week ago). The display is set
>>> above 500nit, so the darks are in fact very bright... E.g, there is no
>>> big deal in distinguishing 0,0,0 from 2,2,2 (at least in "stationary"
>>> images ;-)...
>
>> Hmm, no idea. The default colors use values around 128 for the dark parts.
>
> No, they use values about 0,0,0 for the dark parts. E.g., level=1 is
> mapped to 0,0,4 - which would quite impossible to distinguish from 0,0,0.
? - you just said that you can distinguish 2,2,2 from 0,0,0. Furthermore
the default colors should not introduce any blue. I am wondering.
What kind of analyzer did you use?
For the spectroscope displays it is intended that silent parts fade into
the background. Of course, you may change this. The screen shots in the
documentation are taken with the default colors and look reasonable at
different displays here (including CRTs).
Marcel
Ilya Zakharevich
> The default coordinates are 32, 49, 95, 30 for the default skin.
Thanks!
> I don't know why they changed a few pixels. I think this is a change
> from PM123 1.32.
I do not know whether they changed or not. The values I introduced
were just guesstimates based on analyzing a screenshot... ;-(
>>> Hmm, no idea. The default colors use values around 128 for the dark parts.
>> No, they use values about 0,0,0 for the dark parts. E.g., level=1 is
>> mapped to 0,0,4 - which would quite impossible to distinguish from 0,0,0.
> ? - you just said that you can distinguish 2,2,2 from 0,0,0.
As I said: "in stationary text". Moreover, do you realize that the
difference between 2,2,2 and 0,0,0 is about an order of magnitude more
than between 0,0,4 and 0,0,0?
> Furthermore the default colors should not introduce any blue. I am wondering.
I'm just using the documented values... *My* settings introduce blue
and green, and are easily distinguishable even in quiet parts...
> What kind of analyzer did you use?
Spectroscope.
> For the spectroscope displays it is intended that silent parts fade into
> the background.
Silent - no problem; same happens with my settings. Queit parts
should be still distinguisable from louder ones though, IMO.
> documentation are taken with the default colors and look reasonable at
> different displays here (including CRTs).
What you call "reasonable"? ;-) And which screenshots do you mean here -
I searched for spectors* and did not find any screenshots... Aha, you
probably mean "Sound visualization Plug-in".
The screenshots there do not contain any quiet part, and 3rd one does
not visualize anything in top-right - THIS is where my changes happen.
(Three other quadrants of the 3rd screenshot would be approx. the same
with my settings too, but some blue-and-green info would be shown in
the top-right quadrant as well.)
Hope this helps,
Ilya
Ilya Zakharevich
>> No, they use values about 0,0,0 for the dark parts. E.g., level=1 is
>> mapped to 0,0,4 - which would quite impossible to distinguish from 0,0,0.
> ? - you just said that you can distinguish 2,2,2 from 0,0,0.
Just for your convenience, this illustrates the difference between old
and new display (at 0:29 in Cziffra/List's Sonata B minor)
http://ilyaz.org/software/tmp/pm123-old-new-c.png
Are you sure you can distinguish the same number of gradations on top
as on bottom (especially in moving display?). (An inspection at major
magnification with very strong enhancement of brightness and contrast
SHOWS that the top has a SIMILAR number of gradations; they are just
not visible...)
Thanks,
Ilya