IPB

Welcome Guest ( Log In | Register )

100 Pages V  « < 85 86 87 88 89 > »   
Reply to this topicStart new topic
CUETools versions 1.9.5 through 2.1.5 (current), AccurateRip support & more
themanuel
post Mar 26 2013, 03:59
Post #2151





Group: Members
Posts: 10
Joined: 5-March 13
Member No.: 107021



QUOTE (Gregory S. Chudov @ Mar 25 2013, 20:45) *
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.
Go to the top of the page
+Quote Post
ChronoSphere
post Mar 29 2013, 22:41
Post #2152





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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...

This post has been edited by ChronoSphere: Mar 29 2013, 22:51
Go to the top of the page
+Quote Post
korth
post Mar 29 2013, 23:01
Post #2153





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



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?

This post has been edited by korth: Mar 29 2013, 23:15


--------------------
korth
Go to the top of the page
+Quote Post
ChronoSphere
post Mar 29 2013, 23:05
Post #2154





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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.

This post has been edited by ChronoSphere: Mar 29 2013, 23:25
Go to the top of the page
+Quote Post
korth
post Mar 29 2013, 23:31
Post #2155





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
ChronoSphere
post Mar 30 2013, 15:51
Post #2156





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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.
Go to the top of the page
+Quote Post
korth
post Mar 30 2013, 20:01
Post #2157





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



I'll defer on the first part.
QUOTE
In my case, I have the following structure:
album\files\album.cue
album\track 01.flac
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).
FILE "c:\mymusicfiles\album\track 01.flac" WAVE
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.)

This post has been edited by korth: Mar 30 2013, 20:54


--------------------
korth
Go to the top of the page
+Quote Post
themanuel
post Mar 31 2013, 16:13
Post #2158





Group: Members
Posts: 10
Joined: 5-March 13
Member No.: 107021



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.
Go to the top of the page
+Quote Post
ChronoSphere
post Mar 31 2013, 16:21
Post #2159





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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.

This post has been edited by ChronoSphere: Mar 31 2013, 16:22
Go to the top of the page
+Quote Post
korth
post Mar 31 2013, 18:22
Post #2160





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



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
Go to the top of the page
+Quote Post
themanuel
post Apr 2 2013, 02:16
Post #2161





Group: Members
Posts: 10
Joined: 5-March 13
Member No.: 107021



QUOTE (korth @ Mar 31 2013, 12:22) *
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.
Go to the top of the page
+Quote Post
korth
post Apr 2 2013, 04:08
Post #2162





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



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.

This post has been edited by korth: Apr 2 2013, 04:16


--------------------
korth
Go to the top of the page
+Quote Post
themanuel
post Apr 2 2013, 21:59
Post #2163





Group: Members
Posts: 10
Joined: 5-March 13
Member No.: 107021



QUOTE (korth @ Apr 1 2013, 22:08) *
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.
Go to the top of the page
+Quote Post
ChronoSphere
post Apr 3 2013, 21:29
Post #2164





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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?
Go to the top of the page
+Quote Post
korth
post Apr 3 2013, 22:30
Post #2165





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



Yes, 16-bit 44.1 kHz Stereo CD-DA (Red Book) for input.

This post has been edited by korth: Apr 3 2013, 22:44


--------------------
korth
Go to the top of the page
+Quote Post
mjb2006
post Apr 11 2013, 01:22
Post #2166





Group: Members
Posts: 706
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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
[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
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
[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
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?

This post has been edited by mjb2006: Apr 11 2013, 01:23
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Apr 11 2013, 04:06
Post #2167





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



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.

This post has been edited by Gregory S. Chudov: Apr 11 2013, 04:07


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
korth
post Apr 11 2013, 04:07
Post #2168





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



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]

This post has been edited by db1989: Apr 23 2013, 17:24
Reason for edit: striking statement by request due to new knowledge that it’s false


--------------------
korth
Go to the top of the page
+Quote Post
mjb2006
post Apr 11 2013, 06:20
Post #2169





Group: Members
Posts: 706
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



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 smile.gif). 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?

This post has been edited by mjb2006: Apr 11 2013, 06:32
Go to the top of the page
+Quote Post
ChronoSphere
post Apr 11 2013, 12:37
Post #2170





Group: Members
Posts: 399
Joined: 11-March 07
Member No.: 41384



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 =|
Go to the top of the page
+Quote Post
korth
post Apr 11 2013, 13:51
Post #2171





Group: Members
Posts: 394
Joined: 13-March 11
Member No.: 88969



ChronoSphere,
See this post
QUOTE (Goratrix)
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 (spoon)
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
Go to the top of the page
+Quote Post
FulciLives
post Apr 13 2013, 10:33
Post #2172





Group: Members
Posts: 15
Joined: 1-May 09
From: Pittsburgh, PA i
Member No.: 69423



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!

This post has been edited by FulciLives: Apr 13 2013, 10:34
Go to the top of the page
+Quote Post
Gregory S. Chudo...
post Apr 15 2013, 03:19
Post #2173





Group: Developer
Posts: 683
Joined: 2-October 08
From: Ottawa
Member No.: 59035



QUOTE (FulciLives @ Apr 13 2013, 05:33) *
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 smile.gif

This post has been edited by Gregory S. Chudov: Apr 15 2013, 03:20


--------------------
CUETools 2.1.4
Go to the top of the page
+Quote Post
unfinished.hide
post Apr 15 2013, 06:13
Post #2174





Group: Members
Posts: 8
Joined: 17-February 07
Member No.: 40692



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!) smile.gif

This post has been edited by unfinished.hide: Apr 15 2013, 06:56
Go to the top of the page
+Quote Post
ManekiNeko
post Apr 15 2013, 18:23
Post #2175





Group: Members
Posts: 74
Joined: 7-April 09
Member No.: 68742



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 biggrin.gif

This post has been edited by ManekiNeko: Apr 15 2013, 18:48
Go to the top of the page
+Quote Post

100 Pages V  « < 85 86 87 88 89 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 17th April 2014 - 11:07