Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: cue, accepted by 0.8 and rejected by 0.9 (Read 3700 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

cue, accepted by 0.8 and rejected by 0.9

I've some APE that had been burned into data CD, of course, with cuesheet
Those cuesheets can be load right by Foobar0.8, and occur problem when loaded by foobar0.9.

There're 2 examples that get the same responsion by foobar0.9: "Unable to open item for playback (Error parsing cuesheet: unknown cuesheet item (line 12))"

Example 1.
Code: [Select]
PERFORMER "Ancien"
TITLE "La Divine Liturgie de Saint-Jean Chrysostome"
FILE "CDImage.ape" WAVE
 TRACK 01 AUDIO
   TITLE "Grande Litanie de Paix"
   PERFORMER "Ancien"
   INDEX 01 00:00:00
   REM PLAY_COUNTER 5
   REM PLAY_DATE 271205
   REM PLAY_TIME 200242
   REM COMMENT Chorale Sofia
Direction Dimitre Rouskov ID3G: 12
   REM GENRE Other
   REM DISCID e80ce512
....

Example 2.
Code: [Select]
CATALOG 0008430520204
PERFORMER "Bach, J.S."
TITLE "Ouvertures Nr. 3 & 4"
FILE "CDImage8.ape" WAVE
 TRACK 01 AUDIO
   TITLE "Ouverture Nr. 3 D-dur. I. Ouverture"
   PERFORMER "Bach, J.S."
   ISRC DEA808301401
   INDEX 01 00:00:00
   REM DATE 1989
   REM COMMENT Johann Sebastian Bach (1685-1750)
Ouverture (Suite) Nr. 3 D-dur, BMV 1068
Ouverture (Suite) Nr. 4 D-dur, BMV 1069
Concentus musicus Wien
Conductor Nikolaus Harnoncourt

   REM GENRE classical
   REM DISCID 730b460a
......


It seem to be caused by the difference of phrasing between foobar0.8 and foobar0.9 ?
After having those sentence("Direction Dimitre Rouskov ID3G: 12" in e.g.1, "Ouverture (Suite) Nr. 3 D-dur...Harnoncourt" in e.g.2") deleted and saving changes, the cuesheet can be load normally by foobar0.9.

The question is that I can't modify those cuesheet in CD.
On the premise of having not to modify those cuesheet, is there any way to make foobar0.9 be able to load them normally ?
I do want Nooooooooooooot to copy them back to harddisk for modifying and burn them into CD again.. 

Best regards,
Mebanna.

cue, accepted by 0.8 and rejected by 0.9

Reply #1
Nope there's not, but I think I have a workaround for you:

Make additional cue sheets out of the original ones for all the images and edit them so that 0.9 will accept them, then save them on your harddisk somewhere. Now also edit the FILE "<path>" WAVE lines where you enter the absolute path for those Audio CD Rips pointing to your CD-Drive and the location of the corresponding ape files there on your backup CDs.

That should do the trick.

EDIT: If you want a definite solution to this problem then I think the only way to achieve this is to reburn those backup CDs, but I advise you that you first experiment a little bit with 0.9 because it's behaviour has changed quite a bit. If you think you know how to make CD backups that will work with foobar2000 0.9 again the way you want it then burn them to CD-Rs.

For example 0.9 now supports tag fields like "CUE_TRACK##_COMMENT" to let you set individual comments for every track in single image rips. I'd suggest you keep the cue sheets as slim as possible. But what information is to be stored in the cue sheets and what is to be stored in tags, I can't tell you... for example replaygain info is still stored into the cue sheet by foobar2000 0.9 while other extra info for the individual tracks are stored in the CUE_TRACK-tags now...

...would be great if someone who knows more about this would add it to the wiki, btw.

cue, accepted by 0.8 and rejected by 0.9

Reply #2
Quote
Nope there's not, but I think I have a workaround for you:
............
...would be great if someone who knows more about this would add it to the wiki, btw.
[a href="index.php?act=findpost&pid=375183"][{POST_SNAPBACK}][/a]


Great ! Fandango,
I appreciate your help~

Additional, the way you expressing tags & cuesheets, "CUE_TRACK-tags", is helpful to me to understand the different of tags between sperate-track-mode APE and single image rips.
It has confused me for a long time..

--In the sperate-track-mode APE, tags of individual tracks are really written into each APE files;
--In the single image rips, tags of each tracks are written not into the APE files but into the cuesheet.
Is my comprehension this time right ?

If so, of what you said
Code: [Select]
for example replaygain info is still stored into the cue sheet by foobar2000 0.9 while other extra info for the individual tracks are stored in the CUE_TRACK-tags now...

In single image rips, "replaygain info" and "other extra info" are both stored in the .cue files as different parts ?
Hoping I'm right this time or else make me freak out again...   

Thx~ 

cue, accepted by 0.8 and rejected by 0.9

Reply #3
Quote
--In the sperate-track-mode APE, tags of individual tracks are really written into each APE files;


If you had loaded the individual track files directly into the playlist, then yes.

But if you had loaded a (non-conform) cuesheet (which pointed to the individual track files as sources) then the cuesheet was considered the "source and destination" of tags. But writing tags into the cuesheet is and was never supported for certain kinds of tag fields (don't ask me which). But either way, they simply won't get written into the cuesheet or read from the cuesheet.

Quote
--In the single image rips, tags of each tracks are written not into the APE files but into the cuesheet.
Is my comprehension this time right ?


Not really, certain tag fields get written into the cue sheet but other are written as real tags into the image file.

Quote
If so, of what you said
Code: [Select]
for example replaygain info is still stored into the cue sheet by foobar2000 0.9 while other extra info for the individual tracks are stored in the CUE_TRACK-tags now...

In single image rips, "replaygain info" and "other extra info" are both stored in the .cue files as different parts ?


No, replaygain is a good example of a "tag field" that will be added to the single track sections of a cuesheets.

Code: [Select]
  TRACK 01 AUDIO
   TITLE "King Of The Mountains"
   REM DATE 2004
   REM REPLAYGAIN_TRACK_GAIN -4.57 dB
   REM REPLAYGAIN_TRACK_PEAK 0.999969
   INDEX 01 00:00:00


In fact now the track section of cue sheets (like the one above) will be stripped of certain fields (like PERFORMER for example) when rewritten by fb2k 0.9.

So with CUE_TRACK##_<tag field> I was referring to actual real tag fields. Not a section in a cue sheet but real apev2/id3v2 tag fields.

For example if you let fb2k 0.9 final "update" a certain track, for example track 6 of a single file rip with embedded cue sheet, then it will copy a lot of info out of the cuesheet and out of the already existing tags into new tags like CUE_TRACK06_COMMENT, CUE_TRACK06_TRACKNUMBER, CUE_TRACK06_TOTALTRACKS, CUE_TRACK06_LOGFILE, ... and so on. But these CUE_TRACK## tags will only be added for the tracks that you have edited!

When you simply do "update tracks" (context menu->Properties) without editing any tag fields then fb2k won't write no CUE_TRACK## tags.

Also note that for example when you edit the title of a track it will be added as CUE_TRACK##_TITLE (along with all the other bulk of info) and in the cue sheet, too!

Here are two pictures that will show you how files will look like when you have edited (only one!!!) tracks:

BEFORE
[a href="http://img215.imageshack.us/img215/558/ss0758dz.png" target="_blank"]

Notice the entries LOGFILE and CUE_TRACK01_LOGFILE? It's the EAC log. This disc has 7 tracks which would mean 8 times 810 bytes = 6480 bytes of which 5670 bytes are totally redundant. It's not much but it's not only the extra bytes, it makes editing the tag a bit... complex.

Quote
Hoping I'm right this time or else make me freak out again...   


Well, to be honest. I'm quite confused myself. At the moment I have only a limited grasp of how foobar2000 0.9 final will edit my "CD-imagerips+embeddedcues"-files.

At the moment I tag them the way I think it's best with an external tagging software (Mp3Tag) and then set the file mode to read-only, so fb2k won't mess up my work and all the time spent ripping, tagging and renaming was for nothing. The good thing is tho, that all changes to the tags are not irreversibal, 0.9 won't mess up "INDEX 0/INDEX 1" values nor delete tag fields.  (As long as you don't use Utils->edit cuesheet" )

Although I like the concept of CUE_TRACK##, I'm not happy with its current mode of stuffing my tags full of redundant entries. I hope it changes in the future (but I'm not very optimistic that it will...)... 

I'd be very glad if some of the people who have written this part of the new version would also make a sticky thread and explain the whats, wheres, whys and hows...

Atm, it makes no real sense to me... or well, it's very confusing.

cue, accepted by 0.8 and rejected by 0.9

Reply #4
Great !

Follow your guide, I did some tests about file's MD5 value verifying by "FlashSfv.exe") and got results that fits to your conclusion.
I update my comprehension about cue, tags..etc:
If APE is loaded directly(by double-click *.ape) into Foobar's playlist, new tags(e.g. from FreeDB) can be written into APE really(*.ape's MD5 value changed).
If APE is loaded indirectly(by double-click *.cue) into foobar's playlist, new tags(e.g. from FreeDB) can not be written into APE(*.ape's MD5 value not changed, no matter how you modify *.cue), but into CUE.
(Obviously, my attentions is only limited-part of tags, like "metadata"; other kinds of tags, like playgain, I haven't  test.)

under the first situation, tags(stored in *.ape) do not make sense to the CD-imagerips(single image rips), for not including each track' info; but make sense to APEs in seperate-track-mode for obvious reasons, realizing "play by select" when them are put into playlist tegether.
under the second situation, tags(stored in *.cue) make sens to CD-imagerips(single image rips) but not to seperate-track-APE, for the reason similar as above.
(Sorry, those extreme point ↑ maybe only adapt to people who have the similar habit as mine: rarely collected single song(distinguished from album) for that's hard to get info from freedb. at least, I wouldn't think much of them so far to burning into CD)

So, I decide not to write tags into *.ape anymore, for it will change MD5 value(a important evidence of judging whether the backup-files has damaged or not) of the source file(*.ape) . Look on this way, having badgered with cue(no matter how it's of single image rips, or of seperate-track-APEs) seem to be a nice & smart choice~

Again, thanks for your help and patience on my problem and, English...   

cue, accepted by 0.8 and rejected by 0.9

Reply #5
Forgot sth.

Code: [Select]
....it will copy a lot of info out of the cuesheet and out of the already existing tags into new tags....

The info which is out of cuesheet and existing tags, I can't see clearly.. where it come from if belongs to neither?
Limited to my experience, FreeDB seem to be the only 3th-part info sources(distinguished from cuesheet and existing tags) that can be copy from. but plugin Foo_FreeDB don't offer modifying that aim at a certain track.

Best regard.
mebanna

 

cue, accepted by 0.8 and rejected by 0.9

Reply #6
Maybe you can use this
http://tinyurl.com/c72gwn

this is a useful program links folder to any where you point

for example:
if you have a CDROM "X:\" and you have file
X:\xxx\xx.ape
X:\xxx\xx.cue
but just god damn the FILE line in your cue file like

-----------------------------------
PERFORMER "xxxx"
TITLE "xxx"
FILE "xx.ape"
...
-----------------------------------

It seems to lack for the word 'WAVE' after "xx.ape"
the correct line should be like this

--------------------------
FILE "xx.ape" WAVE
--------------------------

if you want to create a cue file in your C:\
and the file edit like

-----------------------------------
PERFORMER "xxxx"
TITLE "xxx"
FILE "X:\xxx\xx.ape" WAVE
...
-----------------------------------

because foobar2000 ver0.9 cannot play absolute path,
it doesn't work.

So, we can use linkd.exe in cmd line
C:\>linkd "CDROM_X" "X:"  <--- don't type "X:\"
then we have created a folder named CDROM_X
now you can change your cue file such as

-----------------------------------
PERFORMER "xxxx"
TITLE "xxx"
FILE "CDROM_X\xxx\xx.ape" WAVE
...
-----------------------------------

Note, here your CDROM_X in C:\ so your cue must put in C:\
of course you can change the CDROM_X path together with cue file.

Try it.