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: REACT 2 Released (Read 1282353 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

REACT 2 Released

Reply #875
Log filename problem in track mode still exist, cover & cuefiles are working fine now.
...
Code: [Select]
Album & Artist = te'stin"g
- Track mode: logfile = te'stin g - te'stin g.log ... Batch var = te'stin'g - te'stin'g.log
- Image mode: logfile = te'stin'g - { 2004 } te'stin'g.log ... Batch var = te'stin'g - { 2004 } te'stin'g.log
What exactly is the 'problem' here?

EAC will use different log naming schemes for track and image rips (as previously stated).

I explained when I posted 2.0.b16l that the log file may have a different name to the batch file, cuesheets and cover art, if, and only if, the artist or album contains a double quote.

This is not a bug, issue, or any sort of problem: @eaclog@ will always refer to the log, @cover@ will always refer to the cover art, and @albumfile@ will always be the root name of the cuesheets.  If you want to rename these files using REACT's character substitution do it in the config file.

Tested A LOT the cuefile problem I had and I can't trust the cuefile generation at all; the problem is most probably a combination of cd-drive which has problems to read certain "difficult" CDs / EAC gap detection / REACT way of creating cuefiles (timing(?) &/ not stopping when some cuefiles are not created).
- Fixes/mods which I found that lowered problematic cases:
1. Stop extraction when cuefile is not found and give warning message.
2. Use "WinMenuSelectItem($g_eacTitle, $g_eacText, "&Action", "&Detect Gaps")" (also wait "Analyzing" window close) before calling "ControlSend()" functions to create different cuefiles.
...
- So, if the gap analyzing has been done, it seems that everything works fine. It's just the first rip which is problematic (sometimes!) when EAC/REACT is started.
I don't trust the menu and key interactions with EAC; there appears to be too much chance of things not happening, with no way of knowing the result.  Unfortunately, if users want REACT to create cuesheets in track mode, there is no other option.

The current code is supposed to wait until the "Analyzing" dialogue closes. If it doesn't for you then I'm flumoxed.

If you know that there is this issue with your drive then I can only suggest that you manually detect gaps before ripping.

I made a difficult decision: I'm going to wait that EAC gets updated with char conversion & other requested features/fixes and use my own pre-processing batch file (or "real" program made with AutoIt or Visual Basic) for covers and other small things. I've wasted so much time and nerves testing, solving problems, reading & modifying source & cfg files that it's hard to walk away now, but I got to.
Best of luck with it.  Please keep this forum updated.
I'm on a horse.

REACT 2 Released

Reply #876
[quote name='Martin H' date='Nov 27 2007, 01:03' post='532181']

Thanks Martin,

I followed your suggestions (chose the code to leave both of them) with the newest metamp3  and it's now working fine.

Appreciate your time and efforts.

Regards,
Pete

REACT 2 Released

Reply #877
Log filename problem in track mode still exist, cover & cuefiles are working fine now.
...
Code: [Select]
Album & Artist = te'stin"g
- Track mode: logfile = te'stin g - te'stin g.log ... Batch var = te'stin'g - te'stin'g.log
- Image mode: logfile = te'stin'g - { 2004 } te'stin'g.log ... Batch var = te'stin'g - { 2004 } te'stin'g.log
What exactly is the 'problem' here?

EAC will use different log naming schemes for track and image rips (as previously stated).

I explained when I posted 2.0.b16l that the log file may have a different name to the batch file, cuesheets and cover art, if, and only if, the artist or album contains a double quote.

This is not a bug, issue, or any sort of problem: @eaclog@ will always refer to the log, @cover@ will always refer to the cover art, and @albumfile@ will always be the root name of the cuesheets.  If you want to rename these files using REACT's character substitution do it in the config file.

I don't quite get it. You say it's fixed and now you say that it will not be fixed? Or is this a mix up? I'm not talking about renaming! The batch file copy and delete EAC logfile commands fail currently. I thought that we were talking about this after you explained that the user is up to his own when it comes to renaming the coverfile, cuefiles & logfile.
Code: [Select]
COPY /Y "@eaclog@" "EAClog.txt"
=
COPY /Y "D:\Music\RIPPED\EAC\te'stin'g - te'stin'g.log" "EAClog.txt"
The system cannot find the file specified.
...
DEL "@eaclog@"
=
DEL "D:\Music\RIPPED\EAC\te'stin'g - te'stin'g.log"
Could Not Find D:\Music\RIPPED\EAC\te'stin'g - te'stin'g.log

(filename = te'stin g - te'stin g.log)
Now you see? Or am I missing something?

Tested A LOT the cuefile problem I had and I can't trust the cuefile generation at all; the problem is most probably a combination of cd-drive which has problems to read certain "difficult" CDs / EAC gap detection / REACT way of creating cuefiles (timing(?) &/ not stopping when some cuefiles are not created).
- Fixes/mods which I found that lowered problematic cases:
1. Stop extraction when cuefile is not found and give warning message.
2. Use "WinMenuSelectItem($g_eacTitle, $g_eacText, "&Action", "&Detect Gaps")" (also wait "Analyzing" window close) before calling "ControlSend()" functions to create different cuefiles.
...
- So, if the gap analyzing has been done, it seems that everything works fine. It's just the first rip which is problematic (sometimes!) when EAC/REACT is started.
I don't trust the menu and key interactions with EAC; there appears to be too much chance of things not happening, with no way of knowing the result.  Unfortunately, if users want REACT to create cuesheets in track mode, there is no other option.

The current code is supposed to wait until the "Analyzing" dialogue closes. If it doesn't for you then I'm flumoxed.

Yes it waits of course IF that window appears.. sometimes that window never comes up, EAC just does something for a while and then it shows error message.. actually most of the time, it doesn't show the error message and some cuefiles are not created or are created wrongly. It's too random to get hold of what's the real problem. I know, I added lots of debug points to code. And tried different methods changing the code, no avail.. like I said, it's too random and I can't see the EAC code, so it's useless to go on with this. All I'm saying that I found methods to make it fail less. And generally, in my opinion, it's stupid not to stop the process and give error message if for some reason one of the cuefile generation fails. I just don't see that the
Code: [Select]
fDebugPrint("Unable to move '" & $src & "'. File does not exist")
line is enough.. give error message, del all cuefiles (if exists) and stop the process.. that's my suggestion. Currently the poor user don't have a clue if something goes wrong. It's hard to detect if you're not sharp because all cuefiles are created EVERY time, even if cuefile generation fails. Weird? No, the "culprit" is REACT code that appends meta data from INI (fLoadAndResaveCuesheet() function). It creates missing cuefiles and fills them with additional meta data from INI.

And like you said, there's no other option to create the cuesheets currently. Were basically stuck and only thing that would change that is that EAC changes. I came to REACT when I wanted to automate tasks when I rip music. The reason not to use the EAC/REACT combination is that I can't rely on it to do all properly everytime. But hey, don't get me wrong, REACT is pushing the envelope right now and it's doing great job with the building blocks EAC gives it.

REACT 2 Released

Reply #878
I don't quite get it. You say it's fixed and now you say that it will not be fixed? Or is this a mix up? I'm not talking about renaming! The batch file copy and delete EAC logfile commands fail currently.
...
Now you see? Or am I missing something?
OK, I think I have worked out what the issue is here.

You are testing with a disc with a data track.  Because of the "EAC tells REACT the wrong number of tracks" issue the log file name issue is not resolved.

The only way I could resolve the log file naming issue - as you've probably seen from the code - was to wait until the log file has been written and then look for "te[ ']stin[ ']g - te[ ']stin[ ']g.log" (i.e.: any apostrophe can be either an apostrophe or a space) in the working directory.

REACT detirmines whether the log file has been written by... checking the current track number against the total number of tracks.

Ah...

I really did not want to get into fixing the track number issue.  It is going to be yet another hack that requires REACT to tell (via menu command or keystroke) EAC to create a cuesheet.  As previously stated, I have had enough of hacking the code to try to resolve some minor issues, and would rather look at reworking.  Adding this fix will mean the potential of creating new and exciting bugs in the existing code, solely to resolve an issue with a small percentage of discs (that contain data tracks).

To clarify: the issue you are seeing will only happen if you have an artist or album with a double quote in it and a disc with a data track!  You sure do know how to pick 'em!

Oh, I don't know...

This is a dilema I have had before (2.0.b17 to name one): do I fix an issue that may occur in one disc in a hundred (or a few thousand for the log file issue) and jeopardise the way REACT runs for all the other discs?
I'm on a horse.

REACT 2 Released

Reply #879
OK, I think I have worked out what the issue is here.

You are testing with a disc with a data track.  Because of the "EAC tells REACT the wrong number of tracks" issue the log file name issue is not resolved.

The only way I could resolve the log file naming issue - as you've probably seen from the code - was to wait until the log file has been written and then look for "te[ ']stin[ ']g - te[ ']stin[ ']g.log" (i.e.: any apostrophe can be either an apostrophe or a space) in the working directory.

REACT detirmines whether the log file has been written by... checking the current track number against the total number of tracks.

Forget all that, why can't we use the Global $gui_album, $gui_artist variables to our advantage? They contain the true values taken from EAC window. Do StringReplace($gui_artist, '"', ' ') to both of them, concatenate vars to the format eaclog file is (artist - album.log) and assign that to the eaclog var which goes to batch file use. Actually this is the same solution I suggested a while ago. Sorry for re-opening this but my head again thinks that this could solve the problem without solving the numtracks problem.

EDIT: Actually I'm not quite sure (haven't checked) that the Global $gui_album and $gui_artist variables contains true values all the way thru the code. The variables maybe changed in the source after they've been read initially. Bad design, create new FINAL varibles and use them if $gui_album and $gui_artist are not suited for this task.

EDIT2: After doing StringReplace($gui_artist, '"', ' '), I guess that the vars should be escaped normally with fSubstIllegalChars() function...?

I really did not want to get into fixing the track number issue.  It is going to be yet another hack that requires REACT to tell (via menu command or keystroke) EAC to create a cuesheet.  As previously stated, I have had enough of hacking the code to try to resolve some minor issues, and would rather look at reworking.  Adding this fix will mean the potential of creating new and exciting bugs in the existing code, solely to resolve an issue with a small percentage of discs (that contain data tracks).

To clarify: the issue you are seeing will only happen if you have an artist or album with a double quote in it and a disc with a data track!  You sure do know how to pick 'em!

This is a dilema I have had before (2.0.b17 to name one): do I fix an issue that may occur in one disc in a hundred (or a few thousand for the log file issue) and jeopardise the way REACT runs for all the other discs?

I sure do know how to pick 'em!  Yes. That's why consider myself an expert on testing, still not boasting.  I'm currently choosing a firewall.. guess how hard it's to find a proper one when I find horrible bugs in all firewalls I've tested? For normal programs I could accept little bugs here and there but not in critical apps like firewall and such. Like I said earlier, my "gift" in testing is both a blessing and a curse at the same time.

I see and understand your points.. I had similar thoughts about refactoring REACT (and bug fixing) but what I studied the code, I realized that it would be futile because the real "problem" lies with EAC itself.

As I see it, refactoring doesn't change anything. You don't have any other choice to fix this problem but to create a cuesheet and read how many real audio tracks there are. You can't get the proper "numtracks" value anywhere else. Believe me, I tried to work it out. Only solution is that EAC changes its behaviour. OR, refactoring could solve this only if you do all the encoding and other stuff AFTER EAC has finished ripping all tracks (you simply read all wav-files to get the total number of all tracks). But I guess that's out of the question because it grows the total time used to rip one cd (no parallel extraction & encoding). (Actually it's not refactoring because it changes the "outer" part of the program.)

So I suggest that you, and all others reading this and concerned, should write to the EAC wishlist post (http://www.digital-inn.de/exact-audio-copy-english/34718-wishlist-new-functions-eac.html) and express your feelings strongly to fix the "EAC reports the wrong number of total tracks when CD has DATA track". Also it wouldn't hurt to vote that the already voted "User defined character replacement tables" should get higher priority! I'm going to register there and vote as soon as possible. I think that you, Synthetic Soul, could get more attention if you briefly describe who you are and that you're actually responsible for current REACT development.

 

REACT 2 Released

Reply #880
EDIT: Actually I'm not quite sure (haven't checked) that the Global $gui_album and $gui_artist variables contains true values all the way thru the code. The variables maybe changed in the source after they've been read initially. Bad design, create new FINAL varibles and use them if $gui_album and $gui_artist are not suited for this task.
The processing instance of REACT has no knowledge of $gui_album and $gui_artist.  I don't think that it could extract the values from the EAC main dialogue, because at the time it runs EAC should be focussing the ripping dialogue instead.

As I see it, refactoring doesn't change anything. You don't have any other choice to fix this problem but to create a cuesheet and read how many real audio tracks there are.
Yes, I know that I have to create a cuesheet to get the total tracks (I am currently testing 2.0.ssb16m which does just that).  However, if the code was built around that fact that this was going to happen then it may be a whole lot tider, and easier to maintain.

As we have previously dicussed, a full reworking may choose to create a cuesheet and a DB text file, to record important information that can be used by the processing instance.  If this was known from the start perhaps it would rely less on filenames, parameters and such, and more on solely the data contained within those files...
I'm on a horse.

REACT 2 Released

Reply #881
2.0.ssb16m attempts to resolve the following issues:
  • Track mode: Warning message will now alert you to the fact that a cuesheet could not be renamed.  Abort, Retry, and Ignore.
  • Track mode: Total tracks is now taken from a cuesheet called REACT.cue which will be deleted automatically at the end of the process.
I'm on a horse.

REACT 2 Released

Reply #882
The processing instance of REACT has no knowledge of $gui_album and $gui_artist.  I don't think that it could extract the values from the EAC main dialogue, because at the time it runs EAC should be focussing the ripping dialogue instead.

Ok. It seems that I'm not familiar enough with AutoIt.. usually when I declare a global var in my code (be it any language you like, PHP, Java, VB, etc.), I do expect that I can use it everywhere in that sourcecode.. I guess AutoIt is different somehow. Sorry. No way of passing vars to "processing instance of REACT"?

However, if the code was built around that fact that this was going to happen then it may be a whole lot tider, and easier to maintain.

As we have previously dicussed, a full reworking may choose to create a cuesheet and a DB text file, to record important information that can be used by the processing instance.  If this was known from the start perhaps it would rely less on filenames, parameters and such, and more on solely the data contained within those files...

I agree completely. The code is little convoluted looking now with our problems. Initially it probably was a good idea to build it like it's now. That's normal in software engineering. You've two choices: stab the code and fix bugs with bubblegum OR refactor. Simple.  Any amount of planning is not going to solve all future problems.

REACT 2 Released

Reply #883
Ok. It seems that I'm not familiar enough with AutoIt.. usually when I declare a global var in my code (be it any language you like, PHP, Java, VB, etc.), I do expect that I can use it everywhere in that sourcecode.. I guess AutoIt is different somehow. Sorry. No way of passing vars to "processing instance of REACT"?
The EAC wrapping instance and the processing instance are two totally separate instances of the same executable.
I'm on a horse.

REACT 2 Released

Reply #884
Appreciate your time and efforts.

You are most welcome, mate

Btw, i forgot to say previously that if you rather wanted to stick with metamp3 v0.91 instead of the beta, then just say the word if you don't know how the command-line syntax should be changed

REACT 2 Released

Reply #885
Hello SS. After using dbpoweramp, I decided to give React another try. I unzipped everything into my EAC folder, Opened React, hit F2 to configure it with EAC, made my changes to the config file...But when I hit F4 to do it's thing, a dialog box quickly flashes stating that React cannot find a configuration file. I can't read the entire thing because it closes quickly. Halp?

REACT 2 Released

Reply #886
Download the original REACT version and extract it.
Download Synthetic Soul's modded .exe and .cfg's and overwrite the original files with them.
Edit the ini to reflect what you want done.
Start REACT.exe and let it configure EAC.
Insert CD and press F10(image_cfg) or F4(track_cfg).

REACT 2 Released

Reply #887
This thread is growing so fast! Seriously, there is a lot of info here that can go into the wiki. I will try and spend some time doing this, but I don't promise anything. 

REACT 2 Released

Reply #888
As we have previously dicussed, a full reworking may choose to create a cuesheet and a DB text file, to record important information that can be used by the processing instance.  If this was known from the start perhaps it would rely less on filenames, parameters and such, and more on solely the data contained within those files...
I agree completely. The code is little convoluted looking now with our problems. Initially it probably was a good idea to build it like it's now. That's normal in software engineering. You've two choices: stab the code and fix bugs with bubblegum OR refactor. Simple.  Any amount of planning is not going to solve all future problems.
No, but REACT will currently cope with 99.5% of situations, so a rewrite to resolve the final few issues should result in a model that can (better) cope with any new issues, which should be few or none.

The EAC wrapping instance and the processing instance are two totally separate instances of the same executable.
I dug up another post of mine in this thread which explains further.
I'm on a horse.

REACT 2 Released

Reply #889
I'm having some weird problems. REACT was working fine for me, I'm not aware of having changed anything, but now it no longer copies the output files at the end of processing. They are all created correctly, but just end up hanging around in the EAC working directory.

I put it in debug mode, and have had a look at both the config and the generated script, but can't see where this copy is even supposed to happen!

Not sure if this has anything to do with it, but I'm running on Vista, and my final destination directory is on a network drive, but yes, I can access it just fine.

Any ideas? I had a search through this thread, but couldn't find anything relevent. Of course, that doesn't mean that it isn't there!!!

REACT 2 Released

Reply #890
The "copy" is supposed to happen during the processing itself. The output directory is specified in (for example) %trackdir_Flac%, so when it passes the command to the flac executable, the flac executable is actually responsible for putting the output file in the correct place.

If everything is being placed in the working directory, perhaps your @outroot@ variable has been modified to what the working directory is?

Try looking at the UserOutputNames section of your ini file.

REACT 2 Released

Reply #891
The EAC wrapping instance and the processing instance are two totally separate instances of the same executable.
I dug up another post of mine in this thread which explains further.
Aahh, of course! Boy, do I feel stupid now.. looking back at my suggestions.. *doh*. 

But to compensate lost dignity: I tested the new version and found couple of things to correct.. and I did. Here it is: EDIT: codebox fudged up rest of my post, so I emailed it to you.

And after this, I should say hello to all of you again because I'm back with REACT! I'm glad I did test the new version because it made me realize some things and now I can explain the "twilight zone" problems I had with cuefiles/gap detection. To keep it short, all can be explained with this: timing! (REACT did things too fast and EAC is/was sometimes slow in its operations.) I can trust cuefile generation again.. and I can get back using REACT. Yes! 

One thing still is not "perfect":
Code: [Select]
2007-11-30 01:56:08  Creating cuesheets
2007-11-30 01:56:09  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[s].cue'
2007-11-30 01:56:23  Unable to move 'D:\Music\RIPPED\EAC\te'stin g.CUE'. File does not exist
2007-11-30 01:56:41  Retrying...
2007-11-30 01:56:41  Creating cuesheets
2007-11-30 01:56:42  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[s].cue'
2007-11-30 01:56:43  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[mg].cue'
2007-11-30 01:56:43  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[m].cue'
2007-11-30 01:56:43  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[mc].cue'
2007-11-30 01:56:44  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[mg].cue'
2007-11-30 01:56:44  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[m].cue'
2007-11-30 01:56:45  Moving 'D:\Music\RIPPED\EAC\te'stin g.CUE' to 'D:\Music\RIPPED\EAC\te'stin'g.[mc].cue'
2007-11-30 01:56:45  Copy Tracks Beginning...
As you can see from the debug log, retrying in the "create all cuesheets" is not perfect because it runs too many cuefile generations... but in my opinion it's not going to create problems because it just overwrites present correct cuefiles. Also it takes so little time to execute that it's not a time waster. I'd leave that like it's now.. bubblegum.  Just bringing this to your attention if you didn't know.

And once again; Synthetic Soul, please consider amending the Nago mod to your mod. It does no harm to users who don't want to change the cfg file. I think Nago wouldn't mind (?)... or at least that's the impression I got. I think that all would agree that: less mods = good.

REACT 2 Released

Reply #892
As you can see from the debug log, retrying in the "create all cuesheets" is not perfect because it runs too many cuefile generations... but in my opinion it's not going to create problems because it just overwrites present correct cuefiles. Also it takes so little time to execute that it's not a time waster. I'd leave that like it's now.. bubblegum.  Just bringing this to your attention if you didn't know.
I wrote the code.  Restarting the process is far safer than trying to move one cuesheet again, as you don't even know if the cuesheet (if it finally exists) is the one you are after, it may be the next in sequence.  As you say, speed is not a major issue, and if you've got to this point (and most  users shouldn't) then it's better to be safe than sorry.

I will try to find time to diff my source and yours, but it might be nice if you just bullet pointed the changes you have made and why here.
I'm on a horse.

REACT 2 Released

Reply #893
And once again; Synthetic Soul, please consider amending the Nago mod to your mod. It does no harm to users who don't want to change the cfg file. I think Nago wouldn't mind (?)... or at least that's the impression I got. I think that all would agree that: less mods = good.
The alternative, of course, is that I cease to release any new fixes and either you or nago take on the mantle; you have both shown an enthusiam to delve into the REACT code - one which sadly has all but drained from me.

I didn't really mean to release another version after 2.0.ssb16l, and I'm still a little confused as to why I did.

All you need to do is PM Jan S to get a wiki account, and then you can update the mod page just as I have done.  I will stop releasing new versions, and the successor can deal with any new bugs, issues, or misunderstandings that users have.
I'm on a horse.

REACT 2 Released

Reply #894
And once again; Synthetic Soul, please consider amending the Nago mod to your mod. It does no harm to users who don't want to change the cfg file. I think Nago wouldn't mind (?)... or at least that's the impression I got. I think that all would agree that: less mods = good.
The alternative, of course, is that I cease to release any new fixes and either you or nago take on the mantle; you have both shown an enthusiam to delve into the REACT code - one which sadly has all but drained from me.

I didn't really mean to release another version after 2.0.ssb16l, and I'm still a little confused as to why I did.

All you need to do is PM Jan S to get a wiki account, and then you can update the mod page just as I have done.  I will stop releasing new versions, and the successor can deal with any new bugs, issues, or misunderstandings that users have.

Old habits die hard.

Ok, I see, I already wondered why you didn't update the mod page.. hmm.. I got to think about your suggestion. Initial feeling is that I'd like to participate but not be the only enchilada handling all. I guess I don't have the time to do that either. Multiple "Big Helmets"?

Nago, what do you think? What's your take on this?

But if I decided to accept the honor, I would seriously think about moving REACT development to dedicated website or sourceforge. Now this thread and all wikis & who knows what are too cumbersome to handle. A proper forum is needed for faqs, help, bugs, wishlist, development, etc. Also I would like to think about the separate cfg-files situation; do we update those too & should we amend some of the additional functionalities found in Category:REACT guide. What do you think about these Nago?

I was currently writing the changelog you requested but I guess you don't really need it if you think you're done here...? I don't want to waste the time to write detailed changes if you don't need it.

EDIT: Actually we could stay here if we could get a dedicated forum with subforums like foobar2000 has.

REACT 2 Released

Reply #895
Quote
I'm having some weird problems. REACT was working fine for me, I'm not aware of having changed anything, but now it no longer copies the output files at the end of processing. They are all created correctly, but just end up hanging around in the EAC working directory.

I put it in debug mode, and have had a look at both the config and the generated script, but can't see where this copy is even supposed to happen!

Not sure if this has anything to do with it, but I'm running on Vista, and my final destination directory is on a network drive, but yes, I can access it just fine.

Any ideas? I had a search through this thread, but couldn't find anything relevent. Of course, that doesn't mean that it isn't there!!!

Quote
The "copy" is supposed to happen during the processing itself. The output directory is specified in (for example) %trackdir_Flac%, so when it passes the command to the flac executable, the flac executable is actually responsible for putting the output file in the correct place.

If everything is being placed in the working directory, perhaps your @outroot@ variable has been modified to what the working directory is?

Try looking at the UserOutputNames section of your ini file.

@ Leonlikestrees:
Are you using track or image mode? Check to make sure you have it creating your output directory, that it is changing the working directory to there (PUSHD ...), and that you have left all the MOVE commands in your REACT image CFG.
Code: [Select]
MOVE /Y "@image@" %dest%
MOVE /Y "@cuesheet@" %dest%
MOVE /Y "@eaclog@" %dest%
...


@ Nago:
If Leon' is using image mode then it creates the image in the same directory as whatever temp directory he is ripping to (also where he ought to save his album art). Once the image process is over then it moves all contents to the image directory.

@ Akkurat:
I second your motion to have a subforum for REACT. You suggested to me also that this should have it's own site through sourceforge... probably also a good idea considering how many people are working in this and have their own versions of the code.
OP can't edit initial post when a solution is determined  :'-(

REACT 2 Released

Reply #896
But if I decided to accept the honor, I would seriously think about moving REACT development to dedicated website or sourceforge. Now this thread and all wikis & who knows what are too cumbersome to handle. A proper forum is needed for faqs, help, bugs, wishlist, development, etc. Also I would like to think about the separate cfg-files situation; do we update those too & should we amend some of the additional functionalities found in Category:REACT guide. What do you think about these Nago?
...
EDIT: Actually we could stay here if we could get a dedicated forum with subforums like foobar2000 has.
LMAO. There's no way you are going to get a separate forum (with subforums) for REACT!  Have you compared the number of posts per day to this thread to the number of posts in the foobar forums?

Before you start taking the REACT development away from Hydrogen Audio and this thread I think you need to consider that REACT is actually tycho's application first and foremost, and has gotten to this point with the help of the Hydrogen Audio community.

If you're trying to scare me back into development then you are going the right way.
I'm on a horse.

REACT 2 Released

Reply #897
But if I decided to accept the honor, I would seriously think about moving REACT development to dedicated website or sourceforge. Now this thread and all wikis & who knows what are too cumbersome to handle. A proper forum is needed for faqs, help, bugs, wishlist, development, etc. Also I would like to think about the separate cfg-files situation; do we update those too & should we amend some of the additional functionalities found in Category:REACT guide. What do you think about these Nago?
...
EDIT: Actually we could stay here if we could get a dedicated forum with subforums like foobar2000 has.
LMAO. There's no way you are going to get a separate forum (with subforums) for REACT!  Have you compared the number of posts per day to this thread to the number of posts in the foobar forums?

Before you start taking the REACT development away from Hydrogen Audio and this thread I think you need to consider that REACT is actually tycho's application first and foremost, and has gotten to this point with the help of the Hydrogen Audio community.

If you're trying to scare me back into development then you are going the right way.

I'm not trying to scare you back.  No no.. not at all. But I guess more is merrier.

Okey, reading from your LMAO response, I guess the dedicated forum is out of the question. But I don't understand why the post count should matter? Although isn't 36 pages or 896 replies (and counting) enough for one thread?? I say it's more than enough.

And yes, I had Tycho in my mind. All my comments were initial ponderings what to do to make helping & development easier for users and developers. I've read the Tychos disclaimer and I do know how to fork it and acknowledge his input if it's a good idea to move to elsewhere. And the HA community, yes I acknowledge it too but I think that they also would benefit from actions to make REACT support more easier to use and so on... just initial thoughts.. to get input from users, like you did. Thanks.

REACT 2 Released

Reply #898
I'm having some weird problems. REACT was working fine for me, I'm not aware of having changed anything, but now it no longer copies the output files at the end of processing. They are all created correctly, but just end up hanging around in the EAC working directory.

I put it in debug mode, and have had a look at both the config and the generated script, but can't see where this copy is even supposed to happen!

Not sure if this has anything to do with it, but I'm running on Vista, and my final destination directory is on a network drive, but yes, I can access it just fine.

Any ideas? I had a search through this thread, but couldn't find anything relevent. Of course, that doesn't mean that it isn't there!!!

1. Which version are you using? Original REACT or Synthetic Souls mod?
2. Have you updated REACT since it was working fine? And if yes, can you remember which was the previous version you used?
3. Have you changed the cfg-files? If yes, post the contents of the track.cfg or image.cfg (select the one which you're using) file here using CODEBOX tags.
4. Have you changed the ini-file? If yes, post the contents of this file here using CODEBOX tags.
5. Using track or image mode?
6. What output files aren't copied?
7. What's the artist & album names you're ripping?
8. Does this problem happen with all cd's or with just one cd?

Let's start with these.

REACT 2 Released

Reply #899
But I don't understand why the post count should matter? Although isn't 36 pages or 896 replies (and counting) enough for one thread?? I say it's more than enough.
There is a difference between using more than one thread, and suggesting a dedicated forum with subforums.

I think a "REACT  Wishlist" thread makes sense.  A "REACT development" thread makes sense, if more than one person is developing.  FAQs, guides and help are far better suited to a wiki.  We have one of those, and I'm the only one who has written any supplimentary guides thus far (IIRC).
I'm on a horse.