Skip to main content

Topic: CUETools versions 1.9.5 through 2.1.5 (current) (Read 1306036 times) previous topic - next topic

0 Members and 5 Guests are viewing this topic.
  • themanuel
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2150
It is supposed to just work. I mean, if you specify track artists different from album artist.

Sorry for the silly question.  I was about to retract it because I just ripped an album that had songs from more than one artist and it showed up.
I'm really liking your apps!

Thanks for your support.

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2151
Hmm something I noticed: when verifying albums with CUETools, it looks at both AR and CTDB and reports the result. However when encoding it only checks AR.
Is there an option I'm missing or is it intended?

edit: also, I can't seem to find where I can disable caching. For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...
  • Last Edit: 29 March, 2013, 05:51:03 PM by ChronoSphere

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2152
Quote
Is there an option I'm missing or is it intended?
This is normal behavior. There is no 'Use CTDB' checkbox under 'Mode' on the GUI when 'Encode' is selected under 'Action'.
Quote
also, I can't seem to find where I can disable caching.
http://www.cuetools.net/wiki/CUETools_Adva...tings:_Advanced
Quote
For some reason, even though I already changed the tags with foobar CUETools keeps insisting on writing the old version of tags upon conversion, despite multiple restarts, reopening the folders etc...
Are the old tags still in the CUE file?
  • Last Edit: 29 March, 2013, 06:15:11 PM by korth
korth

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2153
You're right. Though it's kinda a bummer, now I will have to re-verify my whole library after converting it to single tracks :|
One more thing, the "copy albumart tags" option ignores any covers in .png format...

edit: I was about to post that I don't have a "cache" option there when I noticed the scroll bar was not in the topmost position. It was aligned perfectly so that the list started at "Cover Art". And the weird thing is, when I adjust the scroll bar, close the dialog and reopen it, it returns to starting at "Cover Art". And it also only happens when you have the "Cover Art" section expanded. No wonder I couldn't find it lol

edit2: no, both .cue and the files had the same tags. In the end I ended up renaming the folder the files were in temporarily and it saw the new tags.
  • Last Edit: 29 March, 2013, 06:25:10 PM by ChronoSphere

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2154
Quote
One more thing, the "copy albumart tags" option ignores any covers in .png format...
When I tested 'Cover Art Files', jpeg, png, gif and bmp didn't appear to work (only jpg). I already reported this.
korth

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2155
Is there a way to tell CUETools to look for audio files corresponding to a .cue in a different folder? I think this could be possible by creating a custom script, but I couldn't find any reference which variables can be used etc. Something like SetWorkdir="..\" maybe?

In my case, I have the following structure:

album\files\album.cue
album\track 01.flac
...

I apologize if it was asked already, but I can't seem to be able to find anything. Would it be possible to additionally filter by .cue, so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks? Thanks in advance.

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2156
I'll defer on the first part.
Quote
In my case, I have the following structure:[blockquote]album\files\album.cue
album\track 01.flac[/blockquote]
AFAIK, CUETools expects the CUE and EAC LOG to be in the same folder as the audio files. However, if you set the full path for each audio file in the CUE file, CUETools can process that CUE file from another folder (and EAC LOG if in same folder as CUE).
[blockquote]FILE "c:\mymusicfiles\album\track 01.flac" WAVE[/blockquote]
Quote
so that when I select my whole music library, only the .cue files will be used to transcode, not the separate tracks?
You can select to use only the CUE files during batch encoding.
Hint#1: Windows Search c:\mymusicfiles and subfolders for *.cue. Highlight the ones you want to use from the results. Drag them into 'Drag'n'drop mode' window.
Hint#2: Use 'Multiselect Browser mode'. Expand mymusicfiles and desired subfolders. Check the boxes next to the desired CUE files.

(naturally 'c:\mymusicfiles' is only an example of any folder containing music files.)
  • Last Edit: 30 March, 2013, 03:54:20 PM by korth
korth

  • themanuel
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2157
I noticed two possible bugs with CueRipper:

1. It does not remember choice of output format (always goes back to flac, when restarting the program)
2. Album art is always embedded on rips, even when de-selecting the option to do so

I've noticed the above when ripping to ALAC format.

Best Regards.

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2158
Must be something on your end. Mine saves the format fine, didn't try to disable album art embedding, but I think that might be related to CUETools seemingly not saving your settings. If you don't have user profiles enabled, it probably tries to write to C:\, which would fail if it doesn't request administrative privileges. This is assuming you're on win vista or later with UAC enabled.

@Korth: thanks, filtering by .cue in explorer sounds like a good idea. Ticking everything in browser mode isn't so convenient when converting the whole library with ~200 folders.
  • Last Edit: 31 March, 2013, 11:22:57 AM by ChronoSphere

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2159
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.
korth

  • themanuel
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2160
themanuel,
CUERipper settings file location: %appdata%/CUERipper/settings.txt (Windows Key + r will open run box if you want to view the file).
CUERipper needs to write to this file on exit to save any changes.


Thanks, but I may have a different problem.  Other settings seem to save fine.  When I open the settings file it does show the embed album art parameter with a value of 0 but the resulting alac files still have the art embedded within.  Unless either Windows 7 or iTunes is embedding the image from folder.jpg on each track file.

If that's the case, I'll still be scratching my head as to why the format defaults to flac when I restart CueRipper.  I don't really see this option in the settings file, but it happens to be the first option in the drop-down menu and maybe that's why it always start there.  It's no big deal but sometimes I forget to set it back to .m4a when I restart CueRipper and start ripping into flac instead of .m4a.

If somebody can point me to this parameter in the settings file, that would be great.

Thanks again.

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2161
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.
  • Last Edit: 01 April, 2013, 11:16:24 PM by korth
korth

  • themanuel
  • [*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2162
Sorry, I finally had a chance to test these and can confirm both problems. The other setting you were looking for is 'DefaultLosslessFormat=' but it doesn't matter.

Thanks for confirming that.
I do have DefaultLosslessFormat set to .m4a but as you found out, CueRipper still defaults to .flac container when starting up.

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2163
CUETools complains about 2 "albums", one is a digital only release with a sample rate of 48khz, another one is a game rip with a sample rate of 22,5khz. In both cases it says the format is invalid... Files decode fine in foobar though, I assume CUETools only handles 44,1kHz files?

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2164
Yes, 16-bit 44.1 kHz Stereo CD-DA (Red Book) for input.
  • Last Edit: 03 April, 2013, 05:44:13 PM by korth
korth

  • mjb2006
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2165
CUERipper's handling of AccurateRip and CTDB submissions still mystifies me. Today while experimenting with burst mode, I got "AR: rip accurate (44/44), CTDB: disk not present in database, insufficient quality."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:00:37 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

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

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      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

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.32 |  8:43.33 |        32    |    39289 
       2  |  8:43.65 |  7:45.30 |    39290    |    74194 
       3  | 16:29.20 |  8:58.57 |    74195    |  114601 
       4  | 25:28.02 |  6:48.15 |    114602    |  145216 
       5  | 32:16.17 |  7:01.25 |    145217    |  176816 
       6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

     Pre-gap length  0:00:02.42

     Peak level 99.4 %
     Track quality 100.0 %
     Copy CRC E61B076B
     Accurately ripped (confidence 46)  [D94B89C4]
     Copy OK

Track  2

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

     Pre-gap length  0:00:03.73

     Peak level 99.7 %
     Track quality 100.0 %
     Copy CRC 510F5D70
     Accurately ripped (confidence 46)  [151FCAF7]
     Copy OK

Track  3

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

     Pre-gap length  0:00:02.84

     Peak level 100.0 %
     Track quality 100.0 %
     Copy CRC D05202B6
     Accurately ripped (confidence 45)  [EA4F7DF1]
     Copy OK

Track  4

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

     Pre-gap length  0:00:04.42

     Peak level 99.2 %
     Track quality 100.0 %
     Copy CRC 7181379B
     Accurately ripped (confidence 46)  [E419B7F9]
     Copy OK

Track  5

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

     Pre-gap length  0:00:03.73

     Peak level 99.9 %
     Track quality 100.0 %
     Copy CRC 71C4A87B
     Accurately ripped (confidence 46)  [5D270E84]
     Copy OK

Track  6

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

     Pre-gap length  0:00:03.73

     Peak level 99.6 %
     Track quality 100.0 %
     Copy CRC C0C9DC68
     Accurately ripped (confidence 44)  [9E561A14]
     Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why "insufficient quality" for this?

So then I re-ripped in Secure mode, and sure enough, it was acceptable: "AR: rip accurate (44/44), CTDB: disk not present in database, 0Z0vBojTm3ENuDvKLGSe4daWlEw- has been uploaded."

Code: [Select]
[CUETools log; Date: 4/10/2013 6:10:17 PM; Version: 2.1.4]
Pregap length 00:00:32.
[CTDB TOCID: 0Z0vBojTm3ENuDvKLGSe4daWlEw-] disk not present in database.
CUETools DB: insufficient quality.
[AccurateRip ID: 000ba559-003d9dd0-520b1806] found.
Track  [  CRC  |  V2  ] Status
 01    [d94b89c4|f2c2d959] (42+04/46) Accurately ripped
 02    [151fcaf7|54e460d5] (42+04/46) Accurately ripped
 03    [ea4f7df1|e944873a] (41+04/45) Accurately ripped
 04    [e419b7f9|6df12198] (42+04/46) Accurately ripped
 05    [5d270e84|cc7fc6d4] (42+04/46) Accurately ripped
 06    [9e561a14|f49c1ff0] (40+04/44) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL]
 --  100.0 [EDC7DA6E] [899889DB]         
 01  99.4 [E61B076B] [CF1AF1EB]         
 02  99.7 [510F5D70] [932D687A]         
 03  100.0 [D05202B6] [9739E9A7]         
 04  99.2 [7181379B] [01F7F213]         
 05  99.9 [71C4A87B] [5423EDA5]         
 06  99.6 [C0C9DC68] [8AC2AAE9]         

Code: [Select]
CUERipper v2.1.4 Copyright © 2008-12 Grigory Chudov

EAC extraction logfile from 10. April 2013, 18:00

Orchestra Baobab / Pirates Choice

Used drive  : PLDS DVD-RW DH16ABSH  Adapter: 1  ID: 0

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

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      : Yes
Used interface                              : Native Win32 interface for Win NT & 2000
Gap handling                                : Appended to previous track

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.32 |  8:43.33 |        32    |    39289 
       2  |  8:43.65 |  7:45.30 |    39290    |    74194 
       3  | 16:29.20 |  8:58.57 |    74195    |  114601 
       4  | 25:28.02 |  6:48.15 |    114602    |  145216 
       5  | 32:16.17 |  7:01.25 |    145217    |  176816 
       6  | 39:17.42 |  8:03.30 |    176817    |  213071 


Track  1

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[01] Orchestra Baobab - Utrus Horas.wav

     Pre-gap length  0:00:02.42

     Peak level 99.4 %
     Track quality 100.0 %
     Copy CRC E61B076B
     Accurately ripped (confidence 46)  [D94B89C4]
     Copy OK

Track  2

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[02] Orchestra Baobab - Coumba.wav

     Pre-gap length  0:00:03.73

     Peak level 99.7 %
     Track quality 100.0 %
     Copy CRC 510F5D70
     Accurately ripped (confidence 46)  [151FCAF7]
     Copy OK

Track  3

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[03] Orchestra Baobab - Ledi Ndieme M'bodj.wav

     Pre-gap length  0:00:02.84

     Peak level 100.0 %
     Track quality 100.0 %
     Copy CRC D05202B6
     Accurately ripped (confidence 45)  [EA4F7DF1]
     Copy OK

Track  4

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[04] Orchestra Baobab - Werente Serigne.wav

     Pre-gap length  0:00:04.42

     Peak level 99.2 %
     Track quality 100.0 %
     Copy CRC 7181379B
     Accurately ripped (confidence 46)  [E419B7F9]
     Copy OK

Track  5

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[05] Orchestra Baobab - Ray M'bele.wav

     Pre-gap length  0:00:03.73

     Peak level 99.9 %
     Track quality 100.0 %
     Copy CRC 71C4A87B
     Accurately ripped (confidence 46)  [5D270E84]
     Copy OK

Track  6

     Filename I:\New folder\Orchestra Baobab\1982 - Pirates Choice\[06] Orchestra Baobab - Soldadi.wav

     Pre-gap length  0:00:03.73

     Peak level 99.6 %
     Track quality 100.0 %
     Copy CRC C0C9DC68
     Accurately ripped (confidence 44)  [9E561A14]
     Copy OK


All tracks accurately ripped

No errors occurred

End of status report

Why wasn't the burst rip acceptable? It was no better or worse than the secure rip; the output was identical.

And why does the secure rip's .accurip log say "insufficient quality"?! Shouldn't it be the other way around?

Is it unreasonable for me to expect things to make more sense than this? Would it help to enable the detailed log?
  • Last Edit: 10 April, 2013, 08:23:43 PM by mjb2006

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2166
Burst rips are not acceptable (insufficient quality) for CTDB, because if your drive doesn't return C2 errors reliably, there can be any amount of undetected errors in burst mode.
You only know that the rip was actually good because it matched AccurateRip database (on which CTDB no longer relies for various philosophical reasons), and because it matched your second rip (to which it couldn't compare it because it was not yet made and time travel is not yet invented).

Somehow .accurip files have mixed up it seems; The result from the first rip crept up into the second log. I will need to look into that.
  • Last Edit: 10 April, 2013, 11:07:23 PM by Gregory S. Chudov
CUETools 2.1.4

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2167
Did you post the same rip log twice? Both say "extraction logfile from 10. April 2013, 18:00". If not, there is a bug in CUERipper where some of the log data isn't cleared if you rip the same disc a second time without reloading the disc. [Reminder of bug to Gregory]

'Burst' mode is one pass (if no C2) and one pass is insufficient quality to submit when no previous records of that disc exist in the CTDB (AccurateRip data is ignored). I think if you had enabled 'Test and Copy' and both CRCs matched then the quality would be sufficient to submit a new disc record (but Gregory would need to confirm this). 'Secure' mode is a minimum of two passes so the CRCs were double checked and the quality was sufficient to submit a new disc.

Edit: [Gregory beat me to it]
  • Last Edit: 23 April, 2013, 12:24:50 PM by db1989
korth

  • mjb2006
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2168
Thanks for the responses.

The .log files are indeed identical; I didn't post the same one twice (well, I suppose it depends on how you look at it ). In between rips, I renamed the output folder, so it's not a case of an existing file being in the way.

The .accurip files are also identical, except for the date/time and "CUETools DB: insufficient quality." appearing erroneously in the secure rip rather than the burst rip.

How does CUERipper determine whether to make use of C2 pointers?
  • Last Edit: 11 April, 2013, 01:32:34 AM by mjb2006

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2169
Speaking of logs, why are there sometimes entries like:
accurate rip id xxxx found

track1 0+0/0, rip not accurate
...

Can't post the actual log because I can't find the disc which had it atm =|

  • korth
  • [*][*][*][*][*]
CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2170
ChronoSphere,
See [a href='index.php?act=findpost&pid=743235']this post[/a]
Quote from: Goratrix link=msg=0 date=
Do I interpret it correctly, that between November and today, there has been a new submission for this disc, with different data than the previous one, and therefore both of them have been moved to "limbo"? But the disc ID itself stays in the database, so we get this weird 0/0 result?

and this dbpoweramp thread.
Quote from: spoon link=msg=0 date=
A guy rips a disc and gets an incorrect rip as [BBBBBBB] (because of scratch), it submits and this result is in the db. You rip correctly get [AAAAAAAA], submit, now neither results are in the db, 3rd guy rips and submits [AAAAAAAA], now only [AAAAAAAA] appears.
korth

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2171
I'm really trying hard to switch full time to Linux but I find myself using this program a lot (I have Windows 7 in VirtualBox).

I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

Sorry if you find this request an annoying one (like I said I'm sure you've heard it before) but Linux is finally catching on now in a big way and with STEAM now on Linux it will just be getting more and more popular so please consider it.

Thank you!
  • Last Edit: 13 April, 2013, 05:34:11 AM by FulciLives

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2172
I know I know you probably have heard it before but here is another vote for making a native Linux version, or at least a version that works in Linux under WINE etc.

I did read somewhere people have run it with under Linux with MONO but I haven't tried since it only supports WAV and then I assume there is no tagging and that just doesn't sound like a great solution.

It doesn't get a lot of testing, but it should work with MONO, and work almost as good as native applications. Theoretically you can even build a static Linux binary from it using mkbundle from mono-devel. It will compile it to a native application more or less.

And the bit about it only supporting WAV is probably outdated. There are managed FLAC and ALAC codecs in cuetools. If it doesn't work for some reason, it probably doesn't take much work to fix it. It's just a matter of finding time for it, or finding someone willing to find some time
  • Last Edit: 14 April, 2013, 10:20:06 PM by Gregory S. Chudov
CUETools 2.1.4

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2173
I'm currently on linux as well (Linux Mint 14) and the best way around I've found to use CUETools has been with wine + the required .Net libraries installed through the command winetricks. Everything I tested works great so far (transcoding to flac from different formats using libflake, verifying with Accuraterip/CTDB, HDCD decoding) and the only small issue was to set wine envirorment to work as 32bit in my x64 computer or .Net installer would refuse to run.

I also tested CUETools with mono, but the experience wasn't that good. Wine + mono for windows had a very annoying issue. CUETools seemed to work fine, but the progress bar at the botton just disappears with all the info regarding AccurateRip and CTDB, whereas with Mono for linux (no wine needed), the GUI was completely screwed. Could never find the Go button to run it, plus only WAV decoding still applied as it was the only encoder available.

Would love to see a native version for linux though (and CUERipper too!)
  • Last Edit: 15 April, 2013, 01:56:57 AM by unfinished.hide

CUETools versions 1.9.5 through 2.1.5 (current)
Reply #2174
Any idea the correct setup to add fhgaacenc?

I've copied the required files into Cuetools directory and added this:

Path: fhgaacenc.exe
Parameters: --vbr %M - -o %O
Modes: 1 2 3 4 5 6

But it's not working

Error: "fhgaacenc.exe has exited prematurely with code 0: The pipe has been ended."

It seems my parameters are wrong

EDIT: Parameters: --vbr %M - %O  works fine
  • Last Edit: 15 April, 2013, 01:48:24 PM by ManekiNeko