CUETools versions 1.9.5 through 2.1.4 (current), AccurateRip support & more Options

[Fandango]

You can use Mp3Tag for editing the metadata in cue sheets, although it only supports the standard specifiaction, i.e. it's not possible to add 'REM <TAG FIELD> "<TAG DATA>" to a cue sheet with Mp3Tag. Meaning "REM DATE xxxx" is not supported by Mp3Tag, for example.

But it's one thing I like about Mp3Tag actually, because it helps me to clean up cue sheets quickly, for example if they were "redesigned" by foobar2000. All the extra metadata should be stored in tags anyway. Always remember what cue sheets where originally intended for, CD copying. But you wanted it for CD-Text only anyway, so Mp3Tag should be fine for now.

It would a be nice addition to CUE tools since it has a batch processor already, but the more features CUE Tools gets the more problematic will be fitting them all into the current UI, especially with something as UI-space-demanding as cue sheet metadata editing.

This post has been edited by Fandango: Jan 11 2009, 16:43

[mikesas]

I am trying to split a single album FLAC image to multiple FLAC tracks. The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #. The Album Title tag is missing even though it is included in the the .cue. I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly. Any suggestions or help?

Running the latest x64 version on Vista. An example of one of my .cue files attached.

Thanks.

This post has been edited by mikesas: Jan 16 2009, 19:58

Attached File(s)

 Carlos_Santana__John_McLaughlin___Love_Devotion_Surrender.cue.txt ( 1.28K ) Number of downloads: 332

 

[Gregory S. Chudo...]

I am trying to split a single album FLAC image to multiple FLAC tracks. The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #. The Album Title tag is missing even though it is included in the the .cue. I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly. Any suggestions or help?

Running the latest x64 version on Vista. An example of one of my .cue files attached.

Thanks.

I confirm this is a bug, will be fixed in future version. Thanks.

Would it be possible to add a function that uses the Tags to correct (or fill if missing) these entries in the cue sheet?

CUETools has an option to fill missing cue-sheet entries from tags. As far as i remember, it's enabled by default. Limited freedb support is most likely to appear in future versions.
But i'm not really willing to create a powerfull tag editing UI.

Gregory, would it be hard to squeeze in a EAC-compatible CRC (with use of null samples) check into the AR check process chain, so that the CUE Tools log would show the plus-null-sample CRCs for all found offsets? That would make it easy comparing the audio data to an old EAC log that only has the CRC and no AR results possible instead of running a check on that old rip's audio.

Unfortunately CRC32 is a decent CRC, so it is not linear, and i cannot use the trick that i used to simultaneously calculate ArCRC for all offsets. I can easily calculate CRC32 for zero, or any other given offset, but i cannot know in advance for which exactly offsets should i do it. Offsets are found only after all the cd image has been processed, and i'd have to process it again to calculate CRC32 for the offsets that were found.

So i'm afraid i'll have to calculate CRC32 for zero offset only.

[mikesas]

I am trying to split a single album FLAC image to multiple FLAC tracks. The audio appears to split fine, but the individual files are only tagged with the Artist, Track Title, and Track #. The Album Title tag is missing even though it is included in the the .cue. I have tried this with multiple images with the same result so I am assuming that I must have something set up incorrectly. Any suggestions or help?

Running the latest x64 version on Vista. An example of one of my .cue files attached.

Thanks.

I confirm this is a bug, will be fixed in future version. Thanks.

Thanks. You probably know this already, but I also found one where I got no Artist Tag. In this case the .cue did not have PERFORMER for each track. It was only at the top for the Album. If the .cue does not specify a PERFORMER on each track would you take the PERFORMER at the top and use it to set the Artist tag for each Track? I hope that makes sense.

Is it also possible to auto correct for the file names in .cue that is in a RAR?

This post has been edited by mikesas: Jan 16 2009, 21:20

[Bugs.Bunny]

CUETools has an option to fill missing cue-sheet entries from tags. As far as i remember, it's enabled by default. Limited freedb support is most likely to appear in future versions.
But i'm not really willing to create a powerfull tag editing UI.

I did a quick test and manually deleted out all PERFORMER and TITLE entries of a cue sheet and then did an encode. The new generated cue sheet had all the correct entries from the tags!
But to correct the entries this way is rather not so user friendly - I've a few hundred cue sheets. To manually delete out these entries on all of them and then encode is not something I'd like to do.
Maybe it's possible to integrate a drop box that performs the "fill missing cue-sheet entries from tags" function but not only fill - but rather overwrite cue-sheet entries from tags. That would be perfect.
I don't need a tag editing UI in cue tools nor do I need freedb support. Freedb has a lot of typos - I actually create the tags via dbpoweramp's perfect meta - so my tags are "more correct" than the entries from EAC + freedb that I use to create the cue sheets.
I think I'm not the only one using dbpoweramp (rip+tags) + eac (gaps+cue) so this would probably useful for more people.

[Gregory S. Chudo...]

Is it also possible to auto correct for the file names in .cue that is in a RAR?

Maybe it's possible to integrate a drop box that performs the "fill missing cue-sheet entries from tags" function but not only fill - but rather overwrite cue-sheet entries from tags. That would be perfect.

Please, check out the new experimental version (1.9.4) in the first post of this thread.

[tuxman]

Aw I see my translations are somehow.. too long in some fields...
(And incomplete.)



Any chance to get write access on your SVN (maybe a special /lang folder)?

[Gregory S. Chudo...]

Any chance to get write access on your SVN (maybe a special /lang folder)?

Sure. Just e-mail me your sourceforge account name.

And to everyone affected by gas shortages in EU, please consider this CUETools release as my apology for my goverment's idiocy

This post has been edited by Gregory S. Chudov: Jan 17 2009, 05:22

[tuxman]

At least I'm not from Georgia.

You got some PM...

[zer]

I have certainly found the "CUE Sheet Creator" a useful convenience, since I have plenty of rips from before I considered the possibility of "verifyably accuracy" (could care less about reburning cds...)

Unfortunately, such cuesheets are frequently useless because of a non-2second pregap.
since you now use freedb and Musicbrainz for metadata, why not use them to help create the proper cuesheeet/ArID? This would help in any case where the actual flacs are intact (or at least have the right length).

In fact, it could even help make a meaningful check against Ar when some files are truncated, or even missing.
I would like to know how accurate are even my bad rips. In one case, I have a disc where the last track wont rip, but its a bonus track I happen to not care about (it really doesnt belong on the album). It should not be required to make a bogus file of the correct length to check this album...

Sorry if I am taking this too far, but knowing the correct tracklengths should make it possible to check those unfortunate rips where some silence has been trimmed between tracks, by establishing bounds for how much it must be offset shifted to check. Possibly the existing offset-detection could be used on a per-track basis if the length is wrong (within reason), just padded by silence?

[Gregory S. Chudo...]

I have certainly found the "CUE Sheet Creator" a useful convenience, since I have plenty of rips from before I considered the possibility of "verifyably accuracy" (could care less about reburning cds...)

Unfortunately, such cuesheets are frequently useless because of a non-2second pregap.
since you now use freedb and Musicbrainz for metadata, why not use them to help create the proper cuesheeet/ArID? This would help in any case where the actual flacs are intact (or at least have the right length).

In fact, it could even help make a meaningful check against Ar when some files are truncated, or even missing.
I would like to know how accurate are even my bad rips. In one case, I have a disc where the last track wont rip, but its a bonus track I happen to not care about (it really doesnt belong on the album). It should not be required to make a bogus file of the correct length to check this album...

Sorry if I am taking this too far, but knowing the correct tracklengths should make it possible to check those unfortunate rips where some silence has been trimmed between tracks, by establishing bounds for how much it must be offset shifted to check. Possibly the existing offset-detection could be used on a per-track basis if the length is wrong (within reason), just padded by silence?

It makes sense, but it's not all that easy.

I thought about using freedb to calculate Ar ids, but unfortunately freedb id is also based on track lengths, although they are less sensible - seconds instead of frames. So if your files have very slightly different length, there's a chance you will find a freedb entry and it will help you find Ar entry. Most of CDs with pregap, for example, have a pregap of 32 or 33 frames. Frame is 1/75th of a second, so there's less than 50% chance that a presense of pregap will change the offset of given track in seconds. For CD with two tracks, that means that your chance to find it in freedb despite lost pregap is less than 25%. It's about zero for a CD with 10 tracks.

Musicbrains has a way to look up cd entry using the audio itself as a key (audio fingerprinting), but it's a not very mature technology and too few CDs have been fingerprinted so far - i guess mainly because the fingerprinting software itself is proprietary.

This post has been edited by Gregory S. Chudov: Jan 20 2009, 02:26

[zer]

Possibly I misunderstand how you are using freedb/musicbrainz to fill in tags. I figgured you meant using a combination of searching for whatever existing tags, and comparing the disc structure. however, even if you only use them if they are stored in tags, I would still find this idea useful, for example I have some rips from dbpoweramp, that are tagged with cddb id and musicbrainz, I would like to recheck accuraterip in some eventual bulk scan, but do not have any cuesheet. I have one or both of those discids stored in various ways for various ripping schemes and experiments. I just want the bulk verification to work in more cases, since I really had no interest in cuefiles for split albums until this 'verification' idea...

I thought about using freedb to calculate Ar ids, but unfortunately freedb id is also based on track lengths, although they are less sensible - seconds instead of frames. So if your files have very slightly different length, there's a chance you will find a freedb entry and it will help you find Ar entry. Most of CDs with pregap, for example, have a pregap of 32 or 33 frames. Frame is 1/75th of a second, so there's less than 50% chance that a presense of pregap will change the offset of given track in seconds. For CD with two tracks, that means that your chance to find it in freedb despite lost pregap is less than 25%. It's about zero for a CD with 10 tracks.

Ok, freedb ids are calculated by rounded seconds, but the returned xmcd files contain a list of frame-accurate offsets, including (importantly for this purpose) the lead in frame. what it does not include is the lead-out frame, that is why it is not sufficient to calculate ArID. Musicbrainz' ids include the lead-out frame though, and I believe have sufficient information to calculate the ArID...
http://musicbrainz.org/doc/DiscIDCalculation
random example on freedb and musicbrainz
http://www.freedb.org/freedb/misc/7b0eee09
http://musicbrainz.org/show/cdtoc/?cdtocid=121699
so, you can see that this one has a pregap of 32 frames, which is all we need to know to create the right cue sheet (if our files are intact, and the disc itself matched that particular freedb entry, of course)
just noticed I have cds w/ pre-emphasis while grepping cuefiles for pre-gaps, now I must determine what to do w/ those...

Musicbrains has a way to look up cd entry using the audio itself as a key (audio fingerprinting), but it's a not very mature technology and too few CDs have been fingerprinted so far - i guess mainly because the fingerprinting software itself is proprietary.

Quite a lot are fingerprinted, and it does appear to be the "most open" of fingerprinting efforts though, and if I am not mistaken there is an open implementation of the genpuid... I think the main problem with it is the somewhat cumbersome combination of picard tagger, and web forms that are required to effectively contribute to it... anyway, that is an interesting possibility also, but much more difficult, because a fingerprinted track could appear on many different releases, many of which would have differing ArCRCs, due to different offsets and gaps, at least...

generating a cuesheet that is much more likely to be right than assuming the standard pregap using the offsets from freedb or musicbrainz is not so complicated.

This post has been edited by zer: Jan 20 2009, 06:32

[caligae]

I recently acquired my first HDCD. CUETools detects it as HDCD but the 24bit output file is the same as the original file, just quieter. In audacity, if I normalize, invert and mix the tracks together I just get silence.

I've selected "Decode HDCD to 20 bit" and store as 24 bit "lossless" and encoded it to flac.

In the result window I see:
HDCD: peak extend: none, transient filter: some, gain: none

Am I doing something wrong?

[Gregory S. Chudo...]

HDCD: peak extend: none, transient filter: some, gain: none

There are three features in HDCD format: gain ajustment, peak extend and transient filter.
gain ajustment is the most common one.
peak extend is somewhat more rare, because it slightly distorts the sound when played on non-HDCD capable player.
transient filter is the most obscure, and not supported by software decoders.
Your CD is pretty wierd, it only uses the last (unsupported) feature.

This post has been edited by Gregory S. Chudov: Jan 31 2009, 20:49

[caligae]

HDCD: peak extend: none, transient filter: some, gain: none

There are three features in HDCD format: gain ajustment, peak extend and transient filter.
gain ajustment is the most common one.
peak extend is somewhat more rare, because it slightly distorts the sound when played on non-HDCD capable player.
transient filter is the most obscure, and not supported by software decoders.
Your CD is pretty wierd, it only uses the last (unsupported) feature.

Thanks for the clarification. I didn't expect any great difference but wanted to try it. But it probably sounds much better on a hardware player thanks to placebo when the HDCD light is on

[Alex B]

Just wondering why EAC's Accurate Rip claims that the CD is not in the database when CUEtools can find the same CD and detect it as accurate (when using the same EAC ripped disc image file).

I ripped the CD three times with EAC and did the Accurate Rip check with CUEtools twice. All EAC rips were bit to bit identical. Only CUEtools could find the CD from the Accuraterip DB.

The EAC log

CODE

Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 3. February 2009, 21:44

Kerkko Koskinen / Lolita

Used drive : TSSTcorpCDDVDW SH-S202J Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : No
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:48.70 | 0 | 17169
2 | 3:48.70 | 3:06.38 | 17170 | 31157
3 | 6:55.33 | 3:20.37 | 31158 | 46194
4 | 10:15.70 | 2:55.06 | 46195 | 59325
5 | 13:11.01 | 3:07.40 | 59326 | 73390
6 | 16:18.41 | 3:15.04 | 73391 | 88019
7 | 19:33.45 | 3:26.41 | 88020 | 103510
8 | 23:00.11 | 3:11.67 | 103511 | 117902
9 | 26:12.03 | 4:07.04 | 117903 | 136431
10 | 30:19.07 | 3:13.37 | 136432 | 150943
11 | 33:32.44 | 2:51.15 | 150944 | 163783
12 | 36:23.59 | 3:58.59 | 163784 | 181692


Range status and errors

Selected range

Filename D:\Rip\Kerkko Koskinen - Lolita.wav

Peak level 99.4 %
Range quality 100.0 %
Copy CRC 8697AA42
Copy OK

No errors occurred


AccurateRip summary

Track 1 not present in database
Track 2 not present in database
Track 3 not present in database
Track 4 not present in database
Track 5 not present in database
Track 6 not present in database
Track 7 not present in database
Track 8 not present in database
Track 9 not present in database
Track 10 not present in database
Track 11 not present in database
Track 12 not present in database

None of the tracks are present in the AccurateRip database

End of status report

The cue sheet

CODE

REM GENRE Pop
REM DATE 2005
REM DISCID 9509760C
REM COMMENT "ExactAudioCopy v0.99pb4"
PERFORMER "Kerkko Koskinen"
TITLE "Lolita"
FILE "Kerkko Koskinen - Lolita.wav" WAVE
TRACK 01 AUDIO
TITLE "Apilapelto"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500106
INDEX 01 00:00:00
TRACK 02 AUDIO
TITLE "Tätä miestä ei ruoste raiskaa"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500088
INDEX 01 03:48:70
TRACK 03 AUDIO
TITLE "Sata rakastavaista"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500107
INDEX 00 06:53:09
INDEX 01 06:55:33
TRACK 04 AUDIO
TITLE "Elokuun pimeää"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500108
INDEX 00 10:13:66
INDEX 01 10:15:70
TRACK 05 AUDIO
TITLE "Suopursu"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500109
INDEX 00 13:09:18
INDEX 01 13:11:01
TRACK 06 AUDIO
TITLE "Lolita"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500110
INDEX 01 16:18:41
TRACK 07 AUDIO
TITLE "Airot levossa"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500111
INDEX 00 19:31:24
INDEX 01 19:33:45
TRACK 08 AUDIO
TITLE "Olen heittänyt verkon"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500112
INDEX 00 22:58:23
INDEX 01 23:00:11
TRACK 09 AUDIO
TITLE "Kitara"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500113
INDEX 00 26:09:29
INDEX 01 26:12:03
TRACK 10 AUDIO
TITLE "Ei taida riittää"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500114
INDEX 00 30:16:28
INDEX 01 30:19:07
TRACK 11 AUDIO
TITLE "Kukurukukukuu"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500089
INDEX 00 33:30:22
INDEX 01 33:32:44
TRACK 12 AUDIO
TITLE "Kaislikossa suhisee"
PERFORMER "Kerkko Koskinen"
ISRC >f2K;0500115
INDEX 00 36:20:72
INDEX 01 36:23:59

The CUEtools/AR log:

CODE

[Verification date: 2009-02-03 21:57:30]
[Disc ID: 0011d877-00a66da7-9509760c]
Track [ CRC ] Status
01 [3b4d463f] (06/06) Accurately ripped as in pressing(s) #1
02 [dbf2168a] (06/06) Accurately ripped as in pressing(s) #1
03 [8c92c9b7] (06/06) Accurately ripped as in pressing(s) #1
04 [dd69f8c3] (06/06) Accurately ripped as in pressing(s) #1
05 [106735dd] (06/06) Accurately ripped as in pressing(s) #1
06 [7f2ddd53] (06/06) Accurately ripped as in pressing(s) #1
07 [698782ec] (06/06) Accurately ripped as in pressing(s) #1
08 [4cc36980] (06/06) Accurately ripped as in pressing(s) #1
09 [ca0e347d] (06/06) Accurately ripped as in pressing(s) #1
10 [eac40e26] (06/06) Accurately ripped as in pressing(s) #1
11 [b9717b01] (06/06) Accurately ripped as in pressing(s) #1
12 [c4ca5fed] (06/06) Accurately ripped as in pressing(s) #1

Track [ CRC32 ]
-- [3E0FE8DB]
01 [824DC7B4]
02 [00949257]
03 [2746E5B5]
04 [7089C2D6]
05 [B9D54A6A]
06 [DF68E14E]
07 [D1FB0AFD]
08 [8510A1E5]
09 [CF820C25]
10 [19D966CF]
11 [64D43861]
12 [44E515E3]

[greynol]

Perhaps a bug in EAC. Have you tried it with V0.95 and verified that the disc ID is the same as the one given by CUE Tools?

My recommendation is to send this along to Andre.

[Alex B]

Thanks, greynol.

Possibly it was some kind of temporary glitch with the accurate rip cache files. I cleared the cache files (I didn't post the suspicious results to the DB), restarted the PC and now I can't reproduce the problem.

EAC finds the CD from AR, verifies the tracks correctly and the results are identical with CUETools' results. Certainly it is not a problem with CUETools. If the problem comes back I'll report at the EAC forum.

CODE

Exact Audio Copy V0.99 prebeta 4 from 23. January 2008

EAC extraction logfile from 3. February 2009, 23:25

Kerkko Koskinen / Lolita

Used drive : TSSTcorpCDDVDW SH-S202J Adapter: 1 ID: 0

Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : Yes

Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : No
Used interface : Native Win32 interface for Win NT & 2000

Used output format : Internal WAV Routines
Sample format : 44.100 Hz; 16 Bit; Stereo


TOC of the extracted CD

Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:48.70 | 0 | 17169
2 | 3:48.70 | 3:06.38 | 17170 | 31157
3 | 6:55.33 | 3:20.37 | 31158 | 46194
4 | 10:15.70 | 2:55.06 | 46195 | 59325
5 | 13:11.01 | 3:07.40 | 59326 | 73390
6 | 16:18.41 | 3:15.04 | 73391 | 88019
7 | 19:33.45 | 3:26.41 | 88020 | 103510
8 | 23:00.11 | 3:11.67 | 103511 | 117902
9 | 26:12.03 | 4:07.04 | 117903 | 136431
10 | 30:19.07 | 3:13.37 | 136432 | 150943
11 | 33:32.44 | 2:51.15 | 150944 | 163783
12 | 36:23.59 | 3:58.59 | 163784 | 181692


Range status and errors

Selected range

Filename R:\Temp\Kerkko Koskinen - Lolita.wav

Peak level 99.4 %
Range quality 100.0 %
Copy CRC 8697AA42
Copy OK

No errors occurred


AccurateRip summary

Track 1 accurately ripped (confidence 6) [3B4D463F]
Track 2 accurately ripped (confidence 6) [DBF2168A]
Track 3 accurately ripped (confidence 6) [8C92C9B7]
Track 4 accurately ripped (confidence 6) [DD69F8C3]
Track 5 accurately ripped (confidence 6) [106735DD]
Track 6 accurately ripped (confidence 6) [7F2DDD53]
Track 7 accurately ripped (confidence 6) [698782EC]
Track 8 accurately ripped (confidence 6) [4CC36980]
Track 9 accurately ripped (confidence 6) [CA0E347D]
Track 10 accurately ripped (confidence 6) [EAC40E26]
Track 11 accurately ripped (confidence 6) [B9717B01]
Track 12 accurately ripped (confidence 6) [C4CA5FED]

All tracks accurately ripped

End of status report

This post has been edited by Alex B: Feb 3 2009, 22:51

[Fandango]

Hey Gregory! Isn't it about time to release "CUE Tools 2.0"?

You've added so many new features already, that it's long overdue.

[ggking7]

When I try to verify with AR, I get:

Error: Argument is out of range.
Parameter name: index

Does anyone know what this means?

[zfox]

Error: Argument is out of range.
Parameter name: index

It's a runtime exception.

You can tell us your settings that caused this, like the offset value you used. You could also upload your .cue file.

[ggking7]

Error: Argument is out of range.
Parameter name: index

It's a runtime exception.

You can tell us your settings that caused this, like the offset value you used. You could also upload your .cue file.

I think that was a bad .cue file. I've got a good one now but I'm getting a crash and Stacktrace. I'm doing this in Linux, but it looks like another guy in this thread has it working fine. Any ideas?

$ mono ArCueDotNet.exe file.cue
Stacktrace:
at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream,string) <0xffffffff>
at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream,string) <0x001cc>
at CUETools.Processor.AudioReadWrite.GetAudioSource (string,System.IO.Stream) <0x000cc>
at CUETools.Processor.CUESheet.GetSampleLength (string,System.Collections.Specialized.NameValueCollection&) <0x0008b>
at CUETools.Processor.CUESheet.Open (string) <0x01b38>
at ArCueDotNet.Program.Main (string[]) <0x00100>
at (wrapper runtime-invoke) ArCueDotNet.Program.runtime_invoke_void_string[] (object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
mono [0x514d43]
mono [0x4e3e3c]
/lib/libpthread.so.0 [0x725dc74d0ec0]
/lib/libc.so.6(memcpy+0x35) [0x725dc6f78905]
mono(mono_class_vtable+0x438) [0x4b8ac1]
mono(mono_runtime_class_init+0x112) [0x4b9e41]
mono [0x50309c]
mono [0x43dfec]
[0x4098c139]
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted

[Gregory S. Chudo...]

Hey Gregory! Isn't it about time to release "CUE Tools 2.0"?

Makes sense. But i'd like to hear Moitah's opinion on this first.

This post has been edited by Gregory S. Chudov: Feb 12 2009, 19:14

[Gregory S. Chudo...]

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted

I don't have a linux host to test CUETools with MONO currently.
There have been reports that CUETools modules that contain native code always crash under linux, and this includes FLAC support.
So far there have been reports of successful operation only with .wav files.
In theory, it would be nice to have a pure managed FLAC implementation.
There is a Java FLAC port, jFLAC, someday i might port it to C#.
Or maybe there is a way to make native code work under MONO. Any experts around?
If this is not possible, then using external compresors/decompressors might do the trick.
Would be nice if someone could point me to a public linux server where i could test this.

[Joey B]

Is there a tutoral or any kind explanation of how to use Cuetools ?

I would like to write my files to a different directory using "artist - album" as the folder name and "artist - album" as the name of my single file .wav .

Your program is great !!!!

Joey B.