Ini files. and the 64K filesize limit
Bill in Co
not a big problem. It can be problematic, however, for most CD music
players that rely on an INI file (cdplayer.ini) to store the CD text
(artist, title, etc) information, since once that 64 K filesize is reached
(after playing a whole bunch of different CDs), it hits that limit, and gets
truncated (starting all over again, fresh, with no entries in the new INI
file). I've seen that happen here (using the old MusicMatch Jukebox - a
nice player for its time)
The specific INI file is "cdplayer.ini", found in the \windows directory.
As mentioned, most INI files are under 64 Kbytes anyways, so normally it's
not an issue. And if no minds their CD player just saying Track 1, Track 2,
etc, instead of the artist and title of the tune playing, then it's no big
deal.
Question: was there ever a system file patch to Win98SE that fixed this
issue? By fixed that, I don't mean a "workaround", or something
sidestepping the use of "cdplayer.ini". I mean allowing cdplayer.ini to
exceed 64 K without any issues. (As an aside, Sysedit is limited to 64K,
but one doesn't need to use sysedit here. Also, this 64K limitation seems
to have been dropped in XP)
Bill in Co
98 Guy
> Guess nobody knows anything about this? (or uses a CD player
> anymore?)
The Micro$haft reference to this limitation is here:
http://support.microsoft.com/kb/78346
The "applies to" section only mentions win-3.x, not win-9x/me.
It has been said that the use of the "INI file" has been strongly
deprecated by Macro$oft starting with Win-95 in favor of storing data in
the registry, and deprecated in .NET in favor of XML .config files.
The KB article above mentions the kernel32 API function call
GetPrivateProfileString as being used to access data in .ini files. The
Windows 9x MSDN Library Documentation does not mention any size limit
for a destination buffer.
A trace of the GetPrivateProfileString API Call shows that it thunks
down to 16-Bit Code. Running the GetPrivateProfileString API Call with
a Destination Buffer size >64K Fails.
This 64kb data-size limit seems to apply to a section within a .ini
file, not the over-all size of the file.
A section is denoted by an identifier or label inside a pair of square
brackets.
If you have a large .ini file, you might want to add some [identifier]
sections inside it to see how your application deals with them.
Or strip out any data you don't need to reduce the size.
I'm not quite sure what function or role your .ini file is providing for
you in terms of playback of music CD's.
Presumably when you insert a music CD into your computer's CD player,
you know what CD you're inserting (ie Artist, Album, etc) and you're
holding the CD jewel case in your hand, so you know what the tracks are
even if your software player doesn't know. And not a lot of commercial
CD's have CD-text information (the vast majority don't).
It's not so much that people don't use a CD player any more, it's more
like they rip CD audio to their hard drive, and in the process obtain
CD-text info from the internet (CDDB) and that's how the CD is
identified and how the tracks are names by the ripping software.
Lostgallifreyan
> It's not so much that people don't use a CD player any more, it's more
> like they rip CD audio to their hard drive, and in the process obtain
> CD-text info from the internet (CDDB) and that's how the CD is
> identified and how the tracks are names by the ripping software.
>
Yes, I think that has been a standard way for a while now. I thought about
the CDplayer.ini problem (even looked it up yesterday but was in a deep
three-piper that demanded attention for 36 hours so didn't try to answer).
I think a lot of stuff was limited to 64K. It's the standard 'text control'
limit too, hence the need for small text editors that use more for big files.
INI files were expected to be opened in small editors so that's why the limit
exists.
To work round it neatly enough for seamless operation might not be possible
for CDplayer.ini because to stay compatible with the existing format you'd
need to address a larger file, and invent a way to do it in chunks of 64K
that include a byte that holds a page number, or does something else similar.
Doing this for one tool might break another because that sort of scheme was
never standardised for CDplayer.ini as far as I know.
What might work is something that uses the disk's ID to determine a short-
hand code in CDplayer.ini so a tool can then refer to that to place or fetch
the full strings of text from a larger file, handing them back to the calling
process so that it thinks it's dealing with CDplayer.ini directly. Another
tool seeing CDplayer.ini would render the codes themselves but it wouldn't
break. Question is: did anyone ever make something like this work? I have no
idea because I liked looking at the CD box better than the onscreen text, so
I never got into the habit of using a computerised method, except to tag MP3
or MPC or WV files when I made them. And I'd go to web sites and find
listings or even write them out by hand, I never did this often enough to
find that too hard..
Lostgallifreyan
> This 64kb data-size limit seems to apply to a section within a .ini
> file, not the over-all size of the file.
>
That's interesting but I still think that a total limit of 64K was often
accepted and imposed to make sure that a small text editor could edit
directly. Was it reeally a section size limit, or a start position? Even if
was the size, they had to handle a case where the whole INI file might be one
big section..
98 Guy
> Guess nobody knows anything about this? (or uses a CD player
> anymore?)
You might want to look at this:
http://www.autoitscript.com/forum/topic/86014-cdini-database/
(Sort of frontend for Cdplayer.ini - but much more!)
Bill in Co
> Bill in Co wrote:
>
>> Guess nobody knows anything about this? (or uses a CD player
>> anymore?)
>
> The Micro$haft reference to this limitation is here:
>
> http://support.microsoft.com/kb/78346
>
> The "applies to" section only mentions win-3.x, not win-9x/me.
I think it applies to Win9x too, from what I had gleaned elsewhere. But
possibly not WinME (that issue may have been addressed there).
> It has been said that the use of the "INI file" has been strongly
> deprecated by Macro$oft starting with Win-95 in favor of storing data in
> the registry, and deprecated in .NET in favor of XML .config files.
Yeah, I know, MS didn't like it, but a lot of apps use (or used) it, and
it's thus not inconsequential by any means, especially for the Win9x vintage
programs!
> The KB article above mentions the kernel32 API function call
> GetPrivateProfileString as being used to access data in .ini files. The
> Windows 9x MSDN Library Documentation does not mention any size limit
> for a destination buffer.
>
> A trace of the GetPrivateProfileString API Call shows that it thunks
> down to 16-Bit Code. Running the GetPrivateProfileString API Call with
> a Destination Buffer size >64K Fails.
And I do recall reading this about some of those API calls.
> This 64kb data-size limit seems to apply to a section within a .ini
> file, not the over-all size of the file.
>
> A section is denoted by an identifier or label inside a pair of square
> brackets.
>
> If you have a large .ini file, you might want to add some [identifier]
> sections inside it to see how your application deals with them.
There are only two sections (one tiny OptionsSettings, and one big one for
the CD tracks), in cdplayer.ini. So for all practical purposes, there
aren't any "sections" within CDplayer.ini (unlike most INI files), and even
creating some separate ones wouldn't solve the problem, since 1) the CD
player wouldn't even know how to use them separately, and 2) they would
eventually fill up anyways.
> Or strip out any data you don't need to reduce the size.
And that is what I had to do. But if you do this, you'll have to delete
some previously stored CD information. The end result is this: The CD
player can store its CD track information locally on your HD for a limited
number of CDs. Once cdplayer.ini reaches 64K, the file gets truncated (and
all locally stored CD track info is lost). More on this below...
> I'm not quite sure what function or role your .ini file is providing for
> you in terms of playback of music CD's.
>
> Presumably when you insert a music CD into your computer's CD player,
> you know what CD you're inserting (ie Artist, Album, etc) and you're
> holding the CD jewel case in your hand, so you know what the tracks are
> even if your software player doesn't know. And not a lot of commercial
> CD's have CD-text information (the vast majority don't).
OK, here is what happens:
You insert a CD the first time, and using CCDB or whatever, its track
information is retrieved, and then stored in "cdplayer.ini", so that the
next time you insert that same CD, the CD player immediately recognizes it,
and displays the track information. (NB: this discussion has nothing to
do with separate, standalone, home CD players)
IF you don't have that cdplayer.ini (or something comparable) capability,
you'll isntead see Track 01, Track 02, Track 03, etc, on your CD player app,
*unless* you let the program go out once again online to CDDB (or whatever),
and redundantly retrieve the same track information once again (this,
assuming you're connected to the Internet, and hopefully not on dial-up!).
Which is a real waste.
> It's not so much that people don't use a CD player any more, it's more
> like they rip CD audio to their hard drive, and in the process obtain
> CD-text info from the internet (CDDB) and that's how the CD is
> identified and how the tracks are names by the ripping software.
That's fine the first time. But to have to do this repetitively, each and
every time any CD is inserted (especially a same CD you had played before),
seems ridiculous (and you'd HAVE to be online to get it).
So unless the CD track information is also being stored locally on your
harddrive (as in cdplayer.ini), that is exactly what happens. Which means,
of course, you'd have to be connected to the Internet too, to get this.
Bill in Co
> 98 Guy <9...@Guy.com> wrote in news:4DE6C108...@Guy.com:
>
>> This 64kb data-size limit seems to apply to a section within a .ini
>> file, not the over-all size of the file.
>>
>
> That's interesting but I still think that a total limit of 64K was often
> accepted and imposed to make sure that a small text editor could edit
> directly.
Which is what sysedit expects, and can only handle (64K filesize limit).
You remember "sysedit"? The system INI file editor? (kinda like a
dedicated notepad)
Running sysedit, at least as I recall, immediately opened up the four(?)
principal system INI files: Can I remember those? Ugh...
Let's see: from memory, I think it was: windows.ini, system.ini,
control.ini(?),
and something else. I forget now. Well, I'm almost positive the first two
at least are correct, anyways. And I think control.ini is too. But I
think there was another one. I guess I could look, but whatever
> Was it reeally a section size limit, or a start position? Even if
> was the size, they had to handle a case where the whole INI file might be
> one
> big section..
Which is essentially is, in the case of cdplayer.ini, as I explained in my
previous reply just now. So you're right - it's a non-solution for this
issue.
Bill in Co
That is an interesting workaround. I'm not sure how flawless it is
practice, but at least it was an idea!
I had thought (hoped) that by now some single system file in Win9x had been
updated by someone to eliminate that 64K INI filesize barrier, but I guess
not.
Those msfn forums authors sometimes posted some of those "updated" system
files (like shell32.dll). However, even replacing shell32.dll might cause
other issues, so who knows. (That's a pretty significant system file
change!).
Or maybe the 64 K max ini filesize code is limited by command.com, in which
case, it's a dead issue. It's not an earth shaking issue for me anyways,
since I spend more time on XP, but it would be nice to know and might be
useful for others out there who are only using Win95 or Win98 and playing
tons of CDs (and not online all the time). And maybe even WinME (not sure
if that 64K INI filesize limitation was removed then, but I had thought I
had seen somewhere that it might have been).
Lostgallifreyan
news:FY6dnUlYiqC7YHvQ...@earthlink.com:
> Running sysedit, at least as I recall, immediately opened up the four(?)
> principal system INI files: Can I remember those? Ugh...
>
> Let's see: from memory, I think it was: windows.ini, system.ini,
> control.ini(?),
> and something else. I forget now. Well, I'm almost positive the first
> two at least are correct, anyways. And I think control.ini is too.
> But I think there was another one.
Autoexec.bat, Config.sys, System.ini, Win.ini. I like SysEdit,. I rarely see
it but I contemplated including it in my W98 core. At times that quick view
of all four files is exactly what's needed to figure things out.
About that CDplayer.ini, I bet this problem has faced coders and baked
noodles aplenty in the past, and there may well be a way round it. But it
WILL be a workround of sorts, whatever you find. I think the best ones will
likely trake the form of some kind of tiny shell extension that diverts from
CDplayer.ini to a larger file via whatever means is needed to map the data so
the player sees as much data as it needs, within its own limits.
Lostgallifreyan
> IF you don't have that cdplayer.ini (or something comparable)
> capability, you'll isntead see Track 01, Track 02, Track 03, etc, on
> your CD player app, *unless* you let the program go out once again
> online to CDDB (or whatever), and redundantly retrieve the same track
> information once again (this, assuming you're connected to the Internet,
> and hopefully not on dial-up!). Which is a real waste.
>
Does it truncate in a linear way as it fills, or does most-played stuff get
moved to the top of the file? If moved, it's effectively a cache thsat you
can use to enough advantage to minimise the loss to stuff you don't play so
often.
Another trick you can try is to make some basic categorisation of your CD's.
Before playing one, run a batch file for that category, which copies a file
with its track data to CDplayer.ini, after copying out the original to
whatever file it was last copied FROM, etc... You can multiply the capacity
by as many categories as you can figure out and make batch files for. I
remember that at times CDplayer.ini can get borked anyway, and this method
gives some limited protection to the main data copies because if CDplayer.ini
dies you can restore it instead of using its own valid updates to refresh
your data file(s).
it may be possible to code a small tool to automate this too. it takes a
while to spin up a CD, and the ID is taken early, I think. Likely time enough
to fetch the right data file over to CDplayer.ini before CDplayer.ini itself
gets locked and loaded or whatever usually hapens when it's accessed.
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in
> news:FY6dnUlYiqC7YHvQ...@earthlink.com:
>
>> Running sysedit, at least as I recall, immediately opened up the four(?)
>> principal system INI files: Can I remember those? Ugh...
>>
>> Let's see: from memory, I think it was: windows.ini, system.ini,
>> control.ini(?),
>> and something else. I forget now. Well, I'm almost positive the first
>> two at least are correct, anyways. And I think control.ini is too.
>> But I think there was another one.
>
> Autoexec.bat, Config.sys, System.ini, Win.ini. I like SysEdit,. I rarely
> see
> it but I contemplated including it in my W98 core. At times that quick
> view
> of all four files is exactly what's needed to figure things out.
Thanks for the correction. My memory was indeed off a bit. :-)
> About that CDplayer.ini, I bet this problem has faced coders and baked
> noodles aplenty in the past, and there may well be a way round it. But it
> WILL be a workround of sorts, whatever you find. I think the best ones
> will
> likely trake the form of some kind of tiny shell extension that diverts
> from
> CDplayer.ini to a larger file via whatever means is needed to map the data
> so
> the player sees as much data as it needs, within its own limits.
I expect so too. And there was that other one mentioned by 98Guy. But
they're all workarounds. So evidently "simply replacing" (cough) one of
the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing did
for me, for that other problem)
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in
> news:PpGdnQLQw-bGZnvQ...@earthlink.com:
>
>> IF you don't have that cdplayer.ini (or something comparable)
>> capability, you'll isntead see Track 01, Track 02, Track 03, etc, on
>> your CD player app, *unless* you let the program go out once again
>> online to CDDB (or whatever), and redundantly retrieve the same track
>> information once again (this, assuming you're connected to the Internet,
>> and hopefully not on dial-up!). Which is a real waste.
>>
>
> Does it truncate in a linear way as it fills, or does most-played stuff
> get
> moved to the top of the file? If moved, it's effectively a cache thsat you
> can use to enough advantage to minimise the loss to stuff you don't play
> so
> often.
I caught it after the fact, and its size was reduced from 64 KB to about 3
KB when I finally discovered it. I'm pretty sure it was truncated to zero
and then kept adding to it as I played some CDs and finally discovered it.
BTW, it doesn't take a whole bunch of CDs to get to that 64 KB (of text
entries).
As I recall, I roughly estimated the number of CDs (by looking at a full
cdplayer.ini file) at a bit over 100 albums (it was much less than 200 CD
albums).
Of course, that figure will vary a bitwith the amount and length of the
entries in the cdplayer.ini file, but that's in the ballpark.
> Another trick you can try is to make some basic categorisation of your
> CD's.
UGH! No thanks. :-)
> Before playing one, run a batch file for that category, which copies a
> file
> with its track data to CDplayer.ini, after copying out the original to
> whatever file it was last copied FROM, etc...
This (for me) "pre-categorization" would be a non starter.
(ditto on using playlists :-)
> You can multiply the capacity
> by as many categories as you can figure out and make batch files for. I
> remember that at times CDplayer.ini can get borked anyway, and this
> method
> gives some limited protection to the main data copies because if
> CDplayer.ini
> dies you can restore it instead of using its own valid updates to refresh
> your data file(s).
This would just be too much of a PIA :-)
What is really needed is a completely transparent process, so that when any
previously played (and thus CD texted) CD is put into the player, the CD
player would immediately recognize it. I think that means a bunch of
different ini files (assuming this could be set up right in the first place)
would have to be sequentially copied, one by one, to cdplayer.ini, until the
specific ini file having that album info stored in it appeared (assuming
that could be easily determined programatically).
Then if you change CDs, the whole process would have to run again. UGH!!
And since the CD player can only see and use the one, and only one,
"cdplayer.ini" (which is in the windows directory), this would be a real
PIA.
> it may be possible to code a small tool to automate this too. it takes a
> while to spin up a CD, and the ID is taken early, I think. Likely time
> enough
> to fetch the right data file over to CDplayer.ini before CDplayer.ini
> itself
> gets locked and loaded or whatever usually happens when it's accessed.
This too would be a challenge.
Hmmm, another option might be to let "cdplayer.ini" just reach 64K, and when
it does that, somehow, programmatically, automatically delete a few entries
in cdplayer.ini, to keep the filesize under 64K max each time).
(deleting the first in, last out, entries would I think be preferable to
just deleting CD text info from the end, which might be easier)
There would have to be some programatic test on its filesize of course to
see when its close to reaching its limit.
Andrzej P. Wozniak
<news:4DE6C108...@Guy.com> pisze:
> Bill in Co wrote:
>
>> Guess nobody knows anything about this? (or uses a CD player
>> anymore?)
>
> The Micro$haft reference to this limitation is here:
>
> http://support.microsoft.com/kb/78346
>
> The "applies to" section only mentions win-3.x, not win-9x/me.
What about newer articles, where the "applies to" section mentions
applications from MS Office 97, 2000, XP (2002), 2003, 2007 in use with
Windows 95, 98, ME, 2000, XP and Vista?
http://support.microsoft.com/kb/140754
http://support.microsoft.com/kb/223019
http://support.microsoft.com/kb/223021
http://support.microsoft.com/kb/224149
http://support.microsoft.com/kb/224169
http://support.microsoft.com/kb/234623
All these KB articles contain info about cause of errors similar to the next
article:
http://support.microsoft.com/kb/235242
/----
You receive an "Error 1913. Could not update the ini file WIN.INI" error
message when you install Office 2000
[...]
This behavior occurs if one of the following is true:
[...]
-or-
The file size of the Win.ini file is greater than or equal to 64 kilobytes
(64 KB).
\----
And here is an extract from the newest, most complete article I've found:
http://support.microsoft.com/kb/291174
/----
The Win.ini file has incorrect, duplicate, or missing entries
You may need to correct the Win.ini file. To complete this procedure, you
need to know the name of your printer driver.
NOTE: This cause does not apply to Windows Vista, to Microsoft Windows 2000,
or to Microsoft Windows XP. The Win.ini file is used in Microsoft Windows 98
and in Microsoft Windows Millennium Edition (Me) to load certain settings
for the system. In Windows Vista, in Microsoft Windows 2000, and in
Microsoft Windows XP, the Win.ini file is used for backwards compatibility.
1. Click Start, point to Find, and then click Files or Folders.
2. In the Named box, type Win.ini.
3. In the Look in box, click your local hard drive, and then click Find Now.
The Win.ini file is displayed at the bottom of the Find dialog box.
4. Check the file size in the Size column. If it is larger than 64 kilobytes
(KB), the Win.ini file is considered large.
\----
Still not win-9x/me problem?
To be clear, file size limit is just a consequence of a section size limit.
API calls described earlier in this thread allow to open 64 KB of a section
already *existing* in ini file. If you want to create a *new* section, the
same API calls will try to open 64 KB of a whole ini file.
--
Andrzej P. Woźniak us...@pochta.onet.pl (swap z<->h in address)
Lostgallifreyan
dnXeDrIh7oHrQn...@earthlink.com:
> I expect so too. And there was that other one mentioned by 98Guy. But
> they're all workarounds. So evidently "simply replacing" (cough) one of
> the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing did
> for me, for that other problem)
>
Any chance of running eiother Dependency Walker or FileMon on your system and
using Profile or Capture respectively to find out all the sysfiles used to
access CDplayer.ini? I don't know enough to code an answer but it might be
useful to know if it's a capacity problem, or just an addressing one. If
players use the file directly and not via the OS, you couldn't solve this
with a replaced sysfile anyway, but it might be easier to solve directly.
Or you might find a player that can keep its own kind of record based on the
CD's ID. So long as it either makes import easy, or avoids binary data,
transferring your current file content should be easy enough.
98 Guy
alphabetically (by artist, Album name, etc) and you have several files
(ie - cdplayer-A-to-K.ini, cdplayer-L-to-Z.ini) and you move the
contents into their respective files by sorting alphabetically. You
keep each file to 64kb or less.
Then when you want to play a certain CD, you have a batch file that
copies the relavent alpha-sorted ini file to the "real" cdplayer.ini and
then launches the cd player.
So you might have 26 batch files, such as:
playA.bat
playB.bat
playC.bat
(etc)
So most of them would have the same content:
======
copy cdplayer-A-to-K.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======
or
======
copy cdplayer-L-to-Z.ini cdplayer.ini
cdplayer.exe (or what-ever your player is)
======
Lostgallifreyan
> So you might have 26 batch files, such as:
>
> playA.bat
> playB.bat
> playC.bat
> (etc)
>
He vetoed my idea. He's not going to go for THAT. :)
Bill in Co
I think I'd rather give up playing CDs altogether if it came down to that.
:-)
Bill in Co
I think I'd rather give up playing CDs altogether if it came down to having
to do this. :-)
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in news:io-
> dnXeDrIh7oHrQn...@earthlink.com:
>
>> I expect so too. And there was that other one mentioned by 98Guy. But
>> they're all workarounds. So evidently "simply replacing" (cough) one
>> of
>> the Win98 DLLs ain't gonna cut it (like that browse DLL swapping thing
>> did
>> for me, for that other problem)
>>
>
> Any chance of running eiother Dependency Walker or FileMon on your system
> and
> using Profile or Capture respectively to find out all the sysfiles used to
> access CDplayer.ini?
Interesting idea. :-) More below.
> I don't know enough to code an answer but it might be
> useful to know if it's a capacity problem, or just an addressing one. If
> players use the file directly and not via the OS, you couldn't solve this
> with a replaced sysfile anyway, but it might be easier to solve directly.
Well, it *does* seem the issue is tied into the OS. How do I know that?
Well, I have successfully used > 64K cdplayer.ini on my XP system, that's
how. Since it appears to be a non-issue there, I guess we know the answer.
:-)
> Or you might find a player that can keep its own kind of record based on
> the
> CD's ID. So long as it either makes import easy, or avoids binary data,
> transferring your current file content should be easy enough.
I think there are some CD player apps that do something similar to this -
use their own database, and sidestep the problem altogether. Unfortunately
a fair amount don't, however, including my beloved old version of MMJB
(MusicMatch Jukebox) - beloved before it got taken over by another company
and went downhill from then on. (can't recall who, but do recall it
happened).
Just for the record, anybody using a CD player app on Win9x that uses
"cdplayer.ini" to get and store the track info (which I think is a lot, if
not the majority of them), is gonna run into this problem, once they play
around 200 (or less, likely), different CDs, as already mentioned.
Granted, it's not the end of the world, but it is a bit of a PIA.
Bill in Co
Thanks for the info.
It seems I was wrong in thinking it might have been resolved in WinME. I
guess that makes more sense in retrospect, since ME is essentially Win9x at
its core.
Thus, it seems this 64 K filesize limit for INI files wasn't resolved until
XP and later (and also Win2K).
Lostgallifreyan
> Well, it *does* seem the issue is tied into the OS. How do I know
> that? Well, I have successfully used > 64K cdplayer.ini on my XP system,
> that's how. Since it appears to be a non-issue there, I guess we know
> the answer.
>:-)
>
Too many unknowns.. Same player, exactly, on each OS? The only way to be
certain is to trace the files used. No need to go into functions too, unless
coding a precise fix (which I don't know how to do). What matters is that if
you want to replace a sysfile you need to know its name. (I love devilish
jokes). That's not really the point though, if you can be certain that the
player can handle a CDplayer.ini of more than 64KB you're in, somehow, if you
persist in the right direction, which will either be a replacement sysfile
(you might even try a direct transplant from WXP if you can put the original
back from real mode DOS if Bad Things stop rebooting somehow), or it might be
best to look for some tool that is based on intercepting calls to
CDplayer.ini and using its own large file. That's as transparent as it's
likely to get, so any competent fix would be coded along those lines.
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in
> news:c8ednVjeCM91T3rQ...@earthlink.com:
>
>> Well, it *does* seem the issue is tied into the OS. How do I know
>> that? Well, I have successfully used > 64K cdplayer.ini on my XP system,
>> that's how. Since it appears to be a non-issue there, I guess we know
>> the answer.
>> :-)
>>
>
> Too many unknowns.. Same player, exactly, on each OS?
YES. The very same player, same edition. No ambiguities there. And to
add to this, keep in mind that I transferred all my Win9x apps over to WinXP
by using Laplink's PC Mover to move stuff over between PCs. There was no
way I was going to reinstall all of my several hundred apps IF I could
successfully avoid it, which I did.
Yes, installing all apps fresh would have been a cleaner approach, but I
didn't feel like spending a year (or so) reinstalling and customizing
everything all over again, and so I largely avoided that problem by using PC
Mover to transfer my programs AND settings from W98SE to XP. It was nice.
:-)
But to summarize, the proof is in the pudding. And the pudding here spoke:
No cdplayer.ini filesize limit issue - when used on XP :-)
> The only way to be certain is to trace the files used.
Well, not really, per above. :-)
> No need to go into functions too, unless
> coding a precise fix (which I don't know how to do). What matters is that
> if
> you want to replace a sysfile you need to know its name.
Of course. Although since I'm not using my W98 computer very often to play
CDs, I can probably forego going to all this trouble.
> (I love devilish
> jokes). That's not really the point though, if you can be certain that the
> player can handle a CDplayer.ini of more than 64KB you're in,
I am. It's doing it on my XP computer. Q.E.D. :-)
> somehow, if you
> persist in the right direction, which will either be a replacement sysfile
> (you might even try a direct transplant from WXP if you can put the
> original
> back from real mode DOS if Bad Things stop rebooting somehow), or it might
> be best to look for some tool that is based on intercepting calls to
> CDplayer.ini and using its own large file. That's as transparent as it's
> likely to get, so any competent fix would be coded along those lines.
And it would still be a bit of a PIA. :-)
Lostgallifreyan
Then you have your answer. WXP does it with nothing, W98 won't do it with
anything you'll accept. Job done.
Lostgallifreyan
>> play CDs, I can probably forego going to all this trouble.
>>
>>> (I love devilish
>>> jokes). That's not really the point though, if you can be certain that
>>> the player can handle a CDplayer.ini of more than 64KB you're in,
>>
>> I am. It's doing it on my XP computer. Q.E.D. :-)
>>
.
.
>
> Then you have your answer. WXP does it with nothing, W98 won't do it with
> anything you'll accept. Job done.
>
Got to say I find it interesting that you need to resort to WXP to let you
use a method that pretty much died out with W31... Nearly everyone else went
with a method that isn't limited by standard controls in the OS. I'm not sure
how tag files work with CD's but I bet there is a way. Same as ReplayGain
files don't have to be embedded in the files they belong to. Last time I used
any audip player than used CDplayer.ini at all, never mind depended on it,
was 1998. I ran into the same limits you did, and equally soon decided that
converting the CD tracks to MP3 with a decent sound quality solved far more
things, disk space, convenient access, track names, etc... I've got as pile
of CD's that stands nearly three feet from the floor in a corner not five
feet away, but I rarely have to reach for one of them because I did that
once, extracting copies to save myself the trouble ever since. It also makes
sure by optical drives are in perfect order when that really matters, too.
Bill in Co
>>> Of course. Although since I'm not using my W98 computer very often to
>>> play CDs, I can probably forego going to all this trouble.
>>>
>>>> (I love devilish
>>>> jokes). That's not really the point though, if you can be certain that
>>>> the player can handle a CDplayer.ini of more than 64KB you're in,
>>>
>>> I am. It's doing it on my XP computer. Q.E.D. :-)
>>>
>>
>> anything you'll accept. Job done.
For two reasons:
1) I'm using XP much more now, so it's not a big issue for me.
2) All the suggestions proposed are a royal PIA (IMHO) for something so
simple as being able to play a CD of all things! (We're not talking about
reinventing the operating system here to gain some other huge benefits,
afterall - now that might make it different (assuming one is only sticking
to W98, come hell or high water).
> Got to say I find it interesting that you need to resort to WXP to let you
> use a method that pretty much died out with W31... Nearly everyone else
> went
> with a method that isn't limited by standard controls in the OS.
I respectfully disagree. Many of the good older CD player apps, like
MusicMatch Jukebox, rely on and use "cdplayer.ini", so it IS an issue. This
didn't die out with Win3.1. This issue *may* have died out since the advent
of XP and later, however - I'd agree with that correction.
> I'm not sure
> how tag files work with CD's but I bet there is a way. Same as ReplayGain
> files don't have to be embedded in the files they belong to. Last time I
> used
> any audio player that used CDplayer.ini at all, never mind depended on it,
> was 1998.
Wow. I'm not sure what CD player you're (occasionally) using now, that
*doesn't* make use of cdplayer.ini, and yet still *retains* and *displays*
the artist and title and track information. (I mean, without having to go
online each time to get it, over and over again). Hmmm. I guess you may
be using some app that creates its own private database for its own
exclusive use.
> I ran into the same limits you did, and equally soon decided that
> converting the CD tracks to MP3 with a decent sound quality solved far
> more
> things, disk space, convenient access, track names, etc...
Of course. :-) But there are still some times that I'll play a CD...
> I've got as pile
> of CD's that stands nearly three feet from the floor in a corner not five
> feet away, but I rarely have to reach for one of them because I did that
> once, extracting copies to save myself the trouble ever since. It also
> makes
> sure by optical drives are in perfect order when that really matters, too.
Yes, I know. Same here :-)
I have a nice large library of mp3s, too, and I use them much more than the
CD player. But still, on those rarer occasions, it's nice not to have to
deal with this issue, at all.
Lostgallifreyan
dnZ7pQK0gnXXQn...@earthlink.com:
> Wow. I'm not sure what CD player you're (occasionally) using now, that
> *doesn't* make use of cdplayer.ini, and yet still *retains* and *displays*
> the artist and title and track information. (I mean, without having to go
> online each time to get it, over and over again). Hmmm. I guess you may
> be using some app that creates its own private database for its own
> exclusive use.
>
Anything that can go to an online database can do it, and cache the fetch so
it doesn't have to repeat. Foobar2000 would do this, but it saves data as
binary which is lousy if you want to edit, reduce, backup or transplant to
another program. This is why I sidestepped the whole nonsense by extracting
to files on the hard disk so they can be tagged in a consistent way.
Foobar2000, 1by1, WinAmp, MPClassic, all play CD's if you want them too, but
I'm not aware of any of those using CDplayer.ini so I guess there might be
several alternatives to solve the problem of displaying track details. The
actual CD access can be bu DShow, WinAmp plugin, or program-specific code.
track data methods might be just as diverse.
You haven't yet said which CD player program you're using, so I have no idea
about that.
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in news:X9-
> dnZ7pQK0gnXXQn...@earthlink.com:
>
>> Wow. I'm not sure what CD player you're (occasionally) using now, that
>> *doesn't* make use of cdplayer.ini, and yet still *retains* and
>> *displays*
>> the artist and title and track information. (I mean, without having to
>> go
>> online each time to get it, over and over again). Hmmm. I guess you
>> may
>> be using some app that creates its own private database for its own
>> exclusive use.
>>
>
> Anything that can go to an online database can do it, and cache the fetch
> so
> it doesn't have to repeat. Foobar2000 would do this, but it saves data as
> binary which is lousy if you want to edit, reduce, backup or transplant to
> another program.
Yup. But usable, at least, for that one app. So if you have a good CD
player app that works seemlessly with its own database, and which is not
constrained by that 64K limit, that might be the easiest "solution".
> This is why I sidestepped the whole nonsense by extracting
> to files on the hard disk so they can be tagged in a consistent way.
>
> Foobar2000, 1by1, WinAmp, MPClassic, all play CD's if you want them too,
> but I'm not aware of any of those using CDplayer.ini so I guess there
> might be
> several alternatives to solve the problem of displaying track details. The
> actual CD access can be bu DShow, WinAmp plugin, or program-specific code.
> track data methods might be just as diverse.
>
> You haven't yet said which CD player program you're using, so I have no
> idea
> about that.
Sure I did. MMJB (MusicMatch Jukebox). :-)
"1by1" simply uses directories for displaying mp3 ID3tag tag info and
playing *mp3s*.
I don't know how it works with CDs (and the metatag CD text issue, which is
completely different from mp3s, and their ID3 tags).
Ditto on Winamp (which I occasionally use to just play mp3s).
But my assumption is if they can't and don't use "cdplayer.ini", they have
to use a proprietary format database, unique to that one app.
Lostgallifreyan
> Sure I did. MMJB (MusicMatch Jukebox). :-)
>
Three times, each time looking like it was past tense, replaced by something
else since, but never mind...
If it can use DShow codecs or WinAmp plugins there's a chance it might have a
way to get text from a local database independently of CDplayer.ini.
Last I heard of Music Match (till this thread) is it was something many
people were kicking out ten years ago in favour of almost anything else
because it wasn't giving them what they wanted. If it hasn't changed usefully
in that time, maybe they were right, and you will do better to cast a wider
net.
98 Guy
> > So you might have 26 batch files, such as:
> >
> > playA.bat
> > playB.bat
> > playC.bat
> > (etc)
> >
>
> He vetoed my idea. He's not going to go for THAT. :)
My strategy there was that if you did have your ini data divided into
two (or more) groups based on the name of the CD or the artist, that you
might not remember where your dividing line was (alphabetically
speaking) as to what custom ini file contained the information that you
were about to call for.
So if you want to play a CD where the title of the CD begins with J,
then you simply run the batch file "playJ". You've already coded that
batch file to copy a specific custom ini file (containing all the "j"
data) over to cdplayer.ini and then launch the CD player.
98 Guy
win-XP systems.
On XP, when a program wants to open an INI file and use those specific
win-API functions to read and write data to the file, what windows does
is it creates a registry section where it will store the data that you
THINK is being written to an ini file. No actual ini file is created.
If a program tries to read data from an ini file that doesn't yet exist
in the registry, windows will look for the actual file. If it exists,
it will read data from it and write the data to the registry, and from
that point on all reads and writes will be to the registry - not the ini
file as it exists on disk.
This does not apply to any program that does it's own low-level reads
and writes to an ini file and does not use the win-api specific
functions that have been mentioned here previously.
This is what currently happens under windows XP, and probably all other
NT-based OS's. I don't know if they've always done that or of this is
the result of the latest service-packs for those OS's.
98 Guy
> Got to say I find it interesting that you need to resort to WXP
> to let you use a method that pretty much died out with W31...
There are many developers that were and still are using ini files well
after the introduction of XP.
The portability of picking up an entire app and it's ini files and
moving it around on a drive, and even to other systems, is possible when
you don't tie yourself down to using the registry to store data.
98 Guy
> I have a nice large library of mp3s, too, and I use them much
> more than the CD player. But still, on those rarer occasions,
> it's nice not to have to deal with this issue, at all.
I've got about 300 actual commercial audio CD's, and about 3 times that
many stored on my hard drives as (mostly) FLAC files (about 75%) and the
other 25% as 320-kbps mp3 files (all of which I've downloaded at no cost
from file-locker sites like rapidshare, hotfile, etc).
I have about 50 cd's at any given time loaded into my Denon 100-disk CD
changer.
The only time I listen to a real CD is in my den through my 4-speaker
system (Paradigm) connected to my Denon AVR-3300 receiver/amp with the
CD being played by my Denon CD player.
I really have no interest to go and load an audio CD into my computer's
CD player to play probably one or two tracks. If I want to listen to
any audio when sitting in front of my PC, I'll play one of the cd's I
have on file.
This is a long winded way of saying that I can't appreciate the use-case
situation of having a problem with cdplayer.ini having a size limitation
because I can't appreciate any serious use of a computer's CD drive to
play music CD's, at least not to the extent that such playing depends on
actual track or CD identification information that might or might not be
in the ini file.
If you're saying that your CD player software becomes inoperable because
of the 64kb ini file limit, then you need to get a different cd player
program (I suggest VLC).
If you're saying that your CD player software WILL always play your
CD's, but because of the 64kb ini file limit that you won't necessarily
see any track information on the CD that you're playing at the moment,
then I have to ask how critical that information is, given that you are
probably holding the CD case in your hands and can easily glance down at
it to see the track names printed on the back cover.
Lostgallifreyan
Splitting hairs. I suggested categorising, you just specified an arbitrary
way to do it. As it happens I arrange my own stuff alphabetically to avoid
having to think about that. Which is exactly why I know it's a lousy basis
for trying to get even-sized chunks. I'm ok with that because it's all in one
space so that doesn't matter. Just as the english languages makes heavy use
of the letter E, musical artists seem to heavily favour the letters S and T.
Go look at the CD's in any music shop if if you doubt this, it's not unique
to my collection (which isn't even widely representative, but that
distribution still happens in it.
Point being that the moment you subdivide, you have to think about how and
why, because no scheme works as simply as wanted.
Lostgallifreyan
> On XP, when a program wants to open an INI file and use those specific
> win-API functions to read and write data to the file, what windows does
> is it creates a registry section where it will store the data that you
> THINK is being written to an ini file. No actual ini file is created.
>
Could be useful. I suspect the file that handles that will work on W9X too if
it only does registry accesses and mediates calls to another named file.
The preference for registry over INI file is old, M$ aimed at that as early
as W95, it was their explicit purpose for inventing the registry. Which in
turn implies that the methods may be compatible, and acheived by simple
transplant of a file not present natively in W9X.
The main reason for not doing that with CDplayer.ini is sheer size. A huge
registry is a slow registry.
Lostgallifreyan
I do it myself. I meant CDplayer.ini specifically, and its inherent 64K-
limiting methods. I have nothing against storing data in files, I prefer it
that way. I also prefer methods that don't impose unworkable limits on me.
When I made tools in wxLua I coded the whole data storage detail myself
precisely so I did have full control of the file formats and locations.
98 Guy
> > On XP, when a program wants to open an INI file and use those
> > specific win-API functions to read and write data to the file,
> > what windows does is it creates a registry section where it will
> > store the data that you THINK is being written to an ini file.
> > No actual ini file is created.
>
> Could be useful.
You missed the point.
Microsoft *wanted* people to stop using ini files and instead to write
data into the registry. So Microsoft pulled an underhanded trick by
storing ini data in the registry by hook or by crook under the nose of
the programmer.
> The main reason for not doing that with CDplayer.ini is sheer size.
> A huge registry is a slow registry.
Doesn't matter, because it's a done deal. Your ini data will be stored
in the registry of an NT-based machine whether you like it or not,
whether it's a small ini "file" or a large one, whether your a
programmer or user.
Lostgallifreyan
> You missed the point.
>
> Microsoft *wanted* people to stop using ini files and instead to write
> data into the registry.
Are you blind as well as stupid?? If you hadn't selctively snipped THIS:
The preference for registry over INI file is old, M$ aimed at that as early
as W95, it was their explicit purpose for inventing the registry. Which in
turn implies that the methods may be compatible, and acheived by simple
transplant of a file not present natively in W9X.
...instead of READING it, you'd not be prating stuff at me that I just said
to you!
Lostgallifreyan
> Doesn't matter, because it's a done deal. Your ini data will be stored
> in the registry of an NT-based machine whether you like it or not,
> whether it's a small ini "file" or a large one, whether your a
> programmer or user.
>
You evidently don't know much about Lua or anything else that does direct
read/write to file. I could even call them xyz.ini if I wanted to, the OS
isn't going to magically step in the way of my direct accesses.
Lostgallifreyan
news:Xns9EF9150885E...@216.196.109.145:
Never mind, that didn't come out right. My point all along in this thread is
to try to bypass the API if it results in 64K limits on stored settings in
W9X. Trying to maintain seamless compatibilty with CDplayer.ini's native
methods to solve a problem inherent to that system is impossible in that
context, so on W9X there would have to be some direct access made on behalf
of whatever thought it was handling CDplayer.ini.
The main problem is that because this IS true, lots of media players went
their own way instead of developing a common method. The best shot at a
common method would be if this had been solved using a plugin that was widely
used.
98 Guy
> > You missed the point.
> >
> > Microsoft *wanted* people to stop using ini files and instead
> > to write data into the registry.
>
> Are you blind as well as stupid??
I am neither.
> If you hadn't selctively snipped THIS:
>
> The preference for registry over INI file is old, M$ aimed at
> that as early as W95, it was their explicit purpose
> for inventing the registry.
I said practically the same thing above. That is not being debated by
me. Do you think I take an opposing view?
> Which in turn implies that the methods may be compatible,
> and acheived by simple transplant of a file not present
> natively in W9X.
Now that has me scratching my head.
What do you mean by a file not natively in win 9x? What file?
Did you already know that the NT-based OS's were transparently storing
ini-file data to the registry?
Lostgallifreyan
> What do you mean by a file not natively in win 9x? What file?
>
Not a clue. :) But as an NT-kernel OS tends to do things with many thousands
of tiny files, it seems likely a dedicated file is doing it.
> Did you already know that the NT-based OS's were transparently storing
> ini-file data to the registry?
>
Yes, but 'transparent' here just means 'magic' in the Arthur C Clarke sense
of the word. There's no way to avoid either testing, hunting for that file
and seeing if it works equally in W9X, or just living with the limitation or
using a subsystem that doesn't have that limitation (which is what nearly
everyone else has done for over 10 years now).
98 Guy
> > Doesn't matter, because it's a done deal. Your ini data will be
> > stored in the registry of an NT-based machine whether you like
> > it or not, whether it's a small ini "file" or a large one,
> > whether your a programmer or user.
>
> You evidently don't know much about Lua or anything else that
> does direct read/write to file.
What you did not quote is one important fact that I already stated:
Any program that uses the GetPrivateProfileString API function (and the
equivalent "put" function) will have it's ini data stored in the
registry and not in an ini file that it thinks it's reading and writing
to. That is most likely many programs.
Naturally it's obvious that this doesn't (indeed, it can't) apply to any
program that does it's own file reading and writing that does not use
those particular API functions.
Lostgallifreyan
> Naturally it's obvious that this doesn't (indeed, it can't) apply to any
> program that does it's own file reading and writing that does not use
> those particular API functions.
>
Yeah, got that. I correct my own post with a followup. Going to stop there.
The main reason this got heated is not reading what's written in posts
directly being replied to! So I won't waste time making even more words for a
while.
98 Guy
> > What do you mean by a file not natively in win 9x? What file?
>
> Not a clue. :) But as an NT-kernel OS tends to do things with many
> thousands of tiny files, it seems likely a dedicated file is doing
> it.
If you mean that there is a specific DLL file that contains the API
functions "GetPrivateProfileString" and "WritePrivateProfileString", yes
there is.
It's called kernel32.dll.
That file also exists in Windows 98.
> There's no way to avoid either testing, hunting for that file
> and seeing if it works equally in W9X
Again, when you say "that file", do you mean kernel32.dll?
And yes, there is a way to test the functionality of the API functions
"GetPrivateProfileString" and "WritePrivateProfileString" on win-9x vs
win-nt. By functionality, I don't mean whether or not the data is
gotten or written from/to the registry, but whether or not the data can
exceed 64kb. And yes we know that on NT systems, the data can exceed 64
kb.
Lostgallifreyan
>> There's no way to avoid either testing, hunting for that file
>> and seeing if it works equally in W9X
>
> Again, when you say "that file", do you mean kernel32.dll?
>
When I said I didn't know, I meant it. But if it IS in Kernel32.dll then
there's no easy fix, that file is usually large, and extremely OS specific.
If the handling of INI files wasn't farmed out to a small dedicated file,
there is no way to intercept the call except at origin, which is why I insist
that the best shot would be a plugin for some widely used subsystem supported
by many media players.
Either that or code directly for the API in ways that bypass the limitation,
if possible. Bill wanted a fix that doesn't require that, so it's unlikely
he'll get one unless someone already coded it.
I don't know any more than I already said in too many posts here now, so I'm
letting this one go. It isn't something I'd want to solve.
98 Guy
> When I said I didn't know, I meant it. But if it IS in
> Kernel32.dll then there's no easy fix
Don't be so sure.
KernelEx hooks into kernel32.dll and essentially gives windows 98 some
NT-based API functions. This would be the most straight-forward way to
"fix" the 64kb data size limitation for the
Get/Write_PrivateProfileString functions. But it would require that
someone add that capability to kernelex.
Bill in Co
> Bill in Co wrote:
>
>> I have a nice large library of mp3s, too, and I use them much
>> more than the CD player. But still, on those rarer occasions,
>> it's nice not to have to deal with this issue, at all.
>
> I've got about 300 actual commercial audio CD's, and about 3 times that
> many stored on my hard drives as (mostly) FLAC files (about 75%) and the
> other 25% as 320-kbps mp3 files (all of which I've downloaded at no cost
> from file-locker sites like rapidshare, hotfile, etc).
>
> I have about 50 cd's at any given time loaded into my Denon 100-disk CD
> changer.
But this discussion has nothing to do with home CD players - only computer
CD players (which use cdplayer.ini).
Standard home CD players are (or were) often destined to just display
Track1, Track2, etc, unless the home CD player can find that info stored on
the CD *and* it is able to display it. My limited experience with CD
players is that they generally can't do that. But maybe the newer ones can
and do (I don't know).
> The only time I listen to a real CD is in my den through my 4-speaker
> system (Paradigm) connected to my Denon AVR-3300 receiver/amp with the
> CD being played by my Denon CD player.
>
> I really have no interest to go and load an audio CD into my computer's
> CD player to play probably one or two tracks. If I want to listen to
> any audio when sitting in front of my PC, I'll play one of the cd's I
> have on file.
>
> This is a long winded way of saying that I can't appreciate the use-case
> situation of having a problem with cdplayer.ini having a size limitation
> because I can't appreciate any serious use of a computer's CD drive to
> play music CD's, at least not to the extent that such playing depends on
> actual track or CD identification information that might or might not be
> in the ini file.
>
> If you're saying that your CD player software becomes inoperable because
> of the 64kb ini file limit, then you need to get a different cd player
> program (I suggest VLC).
No. Not saying that.
> If you're saying that your CD player software WILL always play your
> CD's, but because of the 64kb ini file limit that you won't necessarily
> see any track information on the CD that you're playing at the moment,
I *am* saying that. And after this happens, all the previously stored tag
info is lost forever, so if I put in a CD I had played before, the track
info is all lost (since the cdplayer.ini file was truncated to zero bytes,
and will be a fresh virgin file).
> then I have to ask how critical that information is, given that you are
> probably holding the CD case in your hands and can easily glance down at
> it to see the track names printed on the back cover.
The point is, I don't want to always have to look at the CD cases when MMJB
(or whatever) is playing the tracks on a CD, just to see what is playing or
what comes next, etc. Just seeing Track1, Track2, etc is a bit inane.
Especially for this century.
Bill in Co
Now all that is interesting! Thanks.
Bill in Co
And I'm guessing that didn't happen, as it probably wasn't high on the
priority list, quite understandably.
The bottom line probably is this (for Win9x users):
Use a CD player app that uses its own locally stored database (not
cdplayer.ini), and stick with that, if this is an issue. Too bad, so sad.
:-)
And as been already pointed out, playing CDs (and even finding and puchasing
CDs, locally) seems to be fading into the distant past ... being replaced by
mp3s and mp3 players.
98 Guy
> > I have about 50 cd's at any given time loaded into my Denon
> > 100-disk CD changer.
>
> But this discussion has nothing to do with home CD players - only
> computer CD players (which use cdplayer.ini).
Yes, I know. It's my way of saying that I don't think it's particularly
ergonomic to enjoy your CD collection via computer vs a multi-disk CD
changer.
(but it would piss me off too if all my CD-text info was nuked because
of this 64kb issue)
> Standard home CD players are (or were) often destined to just
> display Track1, Track2, etc, unless the home CD player can find
> that info stored on the CD *and* it is able to display it.
> My limited experience with CD players is that they generally
> can't do that. But maybe the newer ones can and do
> (I don't know).
Yea, I know what you mean. I've seen very few stand-alone CD players
that will display CD text info.
Let me modify that. I think the problem is not so much that the player
is not capable of CD-text display. The problem is that not many CD's
have CD-text information. I looked into this some time ago. The issue
is that Sony "invented" or created the CD-text protocal or format, and
the only commercial / retail CD's that you'll find with CD-text are for
music labels owned by Sony. No other music labels want to license or
pay royalties to Sony for having CD-text put on their CD's.
If you ask me, what really started the erosion of the sales or
profitability of the music industry (by way of copying and sharing music
CD's between friends) was that anyone that rips or copies a retail music
CD to a CD-R can include CD-text information on the CD-r that the
original retail CD did not have, therefore making the CD-r copy more
valuable or useful than the original retail product. It was really
stupid for the music industry as a whole to not impliment CD-text more
widely.
My 100-disk cd changer (Denon DCM 5000 bought in 1999) does do CD-text.
It even has a PS/2 keyboard where I can enter Album name and track name
information that it will remember for a given disk position.
I think that many CD changers will do CD-text, as well as (some? many?)
in-dash car CD players.
Actually, your best solution is to copy your music CD's to CD-r's and
include the CD-text information on the copy. That way your music player
will have the album and track names right on the CD's, and your original
CD's won't suffer any wear and tear.
Bill in Co
That would be a bit of work (and might not be necessary if it could go
online and access some CDDB, for example. Although the freebie ones often
had errors, since they depended on user feedback as I recall. Still, it
was easier than entering it all manually, a PIA.
> I think that many CD changers will do CD-text, as well as (some? many?)
> in-dash car CD players.
Why? What's so special about CD changers?
I thought we said that the home CD players (and by logical extension, car CD
players) wouldn't be able to do it? (in part due to Sony, and the
royalites issues, as you said)
And to get and display this CD track info, it either has to be:
1) manually entered (a real PIA) and somehow stored, or
2) obtained online thru some CDDB service (nice), or
3) stored on the CD (if we're talking about basic CD players that don't have
a HD, etc) and readable by the CD player.
<snip>
98 Guy
> > I think that many CD changers will do CD-text, as well as
> > (some? many?) in-dash car CD players.
>
> Why? What's so special about CD changers?
CD changers are larger (physically) and have more front-panel space that
can be used for more elaborate user control and information display.
Also, it wouldn't be very ergonomic for a CD changer to NOT display
cd-text information to the user in order for the user to know which of
the 100 to 300 disks he's playing (some cd changers do have up to 300 CD
capacity).
This is what the front of my CD-changer looks like:
http://www.avland.co.uk/denon/dcm5000/dcm5000sml.jpg
In that picture, it's showing a generic "Disk-45" label for the cd it's
currently playing, because that disk does not have CD-text. If it did,
it would be displaying the Album name and song name in a scrolling
(right to left) manner. There's actually 2 turntables inside that
player, so that it can play a track from one cd and instantly play
another track from another CD with no delay. I believe that this unit
was used by some radio stations for this reason. The two turntables can
also be used independently, to supply different audio streams to
different rooms (zones).
When I burn a CD-r and include CD-text info in the burn, my denon CD
changer will display the CD-text info.
I have very few retail music CD's that have CD-text. One CD that I know
for sure has it is a Dixie Chicks CD (I forget what the album is - and
no, it's not my CD. I think one some on it is "goodbye earl" or
something like that).
> I thought we said that the home CD players (and by logical
> extension, car CD players) wouldn't be able to do it?
> (in part due to Sony, and the royalites issues, as you said)
To be honest, I'm not so sure how many CD players do or don't do
CD-text. It's my impression that you need a license from Sony to put
CD-text info on a CD (retail / music CD?), but not necessarily to
impliment a method to read it from the CD.
It could very well be that many CD players that came out in the late
1990's and early 2000's had CD-text capability, but after a while they
dropped it when it became clear that not many commercial music CD's were
using it. Sony finalized the CD-text format in 1997.
The bottom line is this: If your CD player doesn't display any CD-text
info when your playing a retail music CD, it's probably because there is
no CD-text info on the CD, not because your CD player is incapable of
displaying CD-text.
For some interesting info about CD-text, read this:
http://www.surething.com/st/Category.asp?CatCode=JULY02_CDTEXT
You might get a kick out of this:
http://www.youtube.com/watch?v=Axbuyl64qlE
Details here:
Bill in Co
Interesting. So it seems (for the most part) we're stuck in the Stone Age
in this regard, UNLESS you make your own copies of the commercial CDs. What
a PIA. In retrospect, this whole thing is pretty primitive and stupid (but
yes, I read the explanations, and guess they have a point :-)
I guess I could say the same thing about the 8.3 filenames, but since I was
around back then, I'd better not. :-) But at least THAT was eons ago, so
there is some "excuse" for it. Then again, I guess the ASPI thing didn't
come out all that much later, so, whatever. It's just sad that we're kinda
stuck with it (without going through these other hoops).
Lostgallifreyan
That might well be the neatest fix.
(Note that 'easy' is a relative term...)
Lostgallifreyan
news:tomdnbkyee1Y2nXQ...@earthlink.com:
> And I'm guessing that didn't happen, as it probably wasn't high on the
> priority list, quite understandably.
>
Send them polite word. It might be something they'd look into, and find a
heap of other small useful fixes that relate to the same issue. If anyone's
likely to be both able and willing, they might be.
Lostgallifreyan
dynamics of hard disk bearings and 'floating' heads, I'd base such a system
around a computer, every time. Extracting CD's to WAVpack or other lossless
format, then tagging the files, is easier and faster than preparing new
CDR's. A lot more convenient later, too. An entire library backed up or
transferred to a new machine in a few tens of minutes with minimal effort..
(I like removable drive frames too, it's like those cool thingers that Dave
used on Hal 9000 to make it sing Daisy...)