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 1071185 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

REACT 2 Released

Reply #550
[quote name='Synthetic Soul' date='Aug 6 2007, 19:14' post='508772']
[quote name='big_red' post='508706' date='Aug 6 2007, 13:37']I have noticed that my REACT_track.cfg differs from ones others have posted on this thread in that mine has the cover embedding actions under each individual file format heading whereas other posts show a single mention under Post-processing.[/quote]I'm not really au fait with album art practices, but it sounds like it is being embedded, but just in a way that MP3Tag is not expecting.  That said, I find that difficult to believe.  As an experiment you could try processing an album both embedding and not embedding the file and see if the resulting files are the same size or not.  Not much help I'm afraid; I mainly posted to say that your track cfg sounds fine - each section should have a "IF %embed_cover%==1 SET Cover_tag" line.

Thanks for the advice and confirmation of my cfg file Synthetic Soul.
School boy error on my part, I hadn't set the directory in my new install of EAC so Coverdownloader was saving the image in one location and REACT was looking for it in another. All sorted now and working wonderfully.

Cheers,

REACT 2 Released

Reply #551
Ripping is going well except for a small problem where the EAClog is not copied to the track directory and then the cover art and the EAClog are not deleted from the temp directory.

I have run debug and have noticed that the numtracks value is always at 0.  The track value however represents the correct track number.  Therefore because of the line:

Code: [Select]
IF NOT @track@==@numtracks@ GOTO end_post_process


REACT never runs post processes and therefore does not copy the EAClog or delete the temp files.

Is there something in EAC or REACT that I need to set to get it to pass the numtracks value?

I can work around it by simply moving the files after I have ripped a CD but I'm sure I must have missed something.

Thanks for any help

REACT 2 Released

Reply #552
The number of tracks is passed in the parameters to REACT, using EAC's %x token.

Ensure that your command line options are as below:

Code: [Select]
REACT %o %s %d "%a" "%g" "%t" "%n" "%x" "%y" "%m" "%e" "%f" "%b" %r

... or maybe Hit Ctrl+F2 to let REACT reconfigure EAC.
I'm on a horse.

REACT 2 Released

Reply #553
The number of tracks is passed in the parameters to REACT, using EAC's %x token.

Ensure that your command line options are as below:

Code: [Select]
REACT %o %s %d "%a" "%g" "%t" "%n" "%x" "%y" "%m" "%e" "%f" "%b" %r

... or maybe Hit Ctrl+F2 to let REACT reconfigure EAC.


Thanks, "%x" is listed. I did have REACT configure EAC on installation and it does not load the numtracks info when using EAC095pb3.  I have just tried using EAC099pb1 and this does pass the numtracks info but it is unable to find the "@eaclog@" file.
Looking at the file names I can see that the log file created is "artist - album.log" whereas debug states that it can not find "album.log"
Where can I configure what the log file is to be named?

Thanks for the help, sorry if these are basic or stupid questions.

REACT 2 Released

Reply #554
What version of REACT are you using?

It sounds like you may need to upgrade to my mod (the official REACT,  2.0.1 (?), has not been upgraded to deal with the change in log file name with 0.99 prebeta 1 - my mod has).

Edit: Hmmm... I see in post 548 you say you are using 2.0.ssb16 - my latest mod.  Another idea may be that the log file just has not been created yet.  Maybe you should add the code in this article to your CFG.
I'm on a horse.

REACT 2 Released

Reply #555
Edit: Hmmm... I see in post 548 you say you are using 2.0.ssb16 - my latest mod.  Another idea may be that the log file just has not been created yet.  Maybe you should add the code in this article to your CFG.

Excellent, all working as sweet as a nut now.  Thanks for all the help and for the mods it is much appreciated.

REACT 2 Released

Reply #556
Excellent, all working as sweet as a nut now.  Thanks for all the help and for the mods it is much appreciated.
Cool and the Gang.  You're welcome. 

As I posted before, I have created two new CFGs which include that addition, and a few others (TAK processing, disc-related tags, "&" bug fix), which I will include with my mod releases from now on.  There's no reason why any of the amends should <edit>not</edit> (  ) be included - it's a win/win thing.
I'm on a horse.

REACT 2 Released

Reply #557
Thanks again, It is a lot quicker with REACT 2 not having to use different programs for different tasks.
I've tried to get EAC095pb3 to pass the numtracks info to REACT but with no success but EAC099pb1 is cooking on gas.

REACT 2 Released

Reply #558
I've been doing a little work on a couple of points raised by deltadave, and I'm looking for some feedback.

1. Amending the meta.ini system so that values are stored separately for each disc, so that the mod can be used with the Compression Queue.

deltadave highlighted an issue in b15 where the additional meta data (AMD) stored in meta.ini was reset when a new disc was inserted, even though the previous disc was still being processed.  This was fixed in b16 - meta.ini is now only updated just before a disc is ripped.

However, storing the AMD in the same place for every disc still means that b16 cannot be used with the Compression Queue.

I have done some testing, storing the AMD for a disc under the freedb id for the disc, allowing multiple sets to be stored.  To calculate the freedb id before ripping I am creating a cuesheet, extracting the freedb id, and then deleting it - unless CreateAllCuesheets is set in which case I extract it from one of those.  This appears to work OK, although I would like an easier/faster way to get the freedb id before ripping.

I'm a little concerned about the extra overhead and complication of doing this, for the majority of users who don't use the Compression Queue.  I have wondered whether this behaviour could be set with a react.ini setting, e.g.: CompressionQueue=1.

2. Allowing the user to specify whether a token, or all tokens, should not be reset to its default value when a new disc is inserted.

Currently, all tokens are reset to their default values when a new disc is inserted.  I have been looking at ways for users to change this behaviour on a per-token basis.

Unfortunately for me, the way the current system works cannot easily be changed to cope with this.

However, this has led me to think about the AMD dialogue, and question the logic of the current set-up.  Currently the dialogue will let users add, amend and delete tokens.  Does it need to?  Given that you need to amend your CFG to deal with tokens, it's not as if you create new tokens on the spur of the moment - the correct process is to set the default in react.ini and amend your CFG to deal with the token.  It seems to me that you only need to amend token values in the dialogue.  If no-one can suggest otherwise, then it  seems that the dialogue needs a complete revamp. Any suggestions welcome.
I'm on a horse.

REACT 2 Released

Reply #559
I'm sure I have read the answer to this before, but can't find it again...

I use React2 to rip to FLAC and MP3. Album art is embedded for MP3 files, but for FLAC there is a JPEG created called 'folder'.

SO now you're all shaking your heads because you know what I'm about to ask... and I have mine hung in shame... 

How do I ensure that the album art is named specific to artist/album? Can I embed album art into FLAC files the same as MP3?

Thanks.



And sorry... 

REACT 2 Released

Reply #560
I've been doing a little work on a couple of points raised by deltadave, and I'm looking for some feedback.

1. Amending the meta.ini system so that values are stored separately for each disc, so that the mod can be used with the Compression Queue.

deltadave highlighted an issue in b15 where the additional meta data (AMD) stored in meta.ini was reset when a new disc was inserted, even though the previous disc was still being processed.  This was fixed in b16 - meta.ini is now only updated just before a disc is ripped.

However, storing the AMD in the same place for every disc still means that b16 cannot be used with the Compression Queue.

I have done some testing, storing the AMD for a disc under the freedb id for the disc, allowing multiple sets to be stored.  To calculate the freedb id before ripping I am creating a cuesheet, extracting the freedb id, and then deleting it - unless CreateAllCuesheets is set in which case I extract it from one of those.  This appears to work OK, although I would like an easier/faster way to get the freedb id before ripping.

I'm a little concerned about the extra overhead and complication of doing this, for the majority of users who don't use the Compression Queue.  I have wondered whether this behaviour could be set with a react.ini setting, e.g.: CompressionQueue=1.


Is there a reason that you have to look up the freedbid before ripping begins?  Isn't that when the AMD tags are committed?  Why not use the cfg file to echo any values added into a file named with the freedbid using the output redirect (>) operator - ie echo @freedbid@ > @outroot@\@freedbid@.amd  Following that up with an append operator (>>) for any further metadata for that album.

How does EAC know when to do a compression queue? is that switch accessible to react?

2. Allowing the user to specify whether a token, or all tokens, should not be reset to its default value when a new disc is inserted.

Currently, all tokens are reset to their default values when a new disc is inserted.  I have been looking at ways for users to change this behaviour on a per-token basis.

Unfortunately for me, the way the current system works cannot easily be changed to cope with this.

However, this has led me to think about the AMD dialogue, and question the logic of the current set-up.  Currently the dialogue will let users add, amend and delete tokens.  Does it need to?  Given that you need to amend your CFG to deal with tokens, it's not as if you create new tokens on the spur of the moment - the correct process is to set the default in react.ini and amend your CFG to deal with the token.  It seems to me that you only need to amend token values in the dialogue.  If no-one can suggest otherwise, then it  seems that the dialogue needs a complete revamp. Any suggestions welcome.


I agree, amending values is probably the right way to do it. I'd also like to recommend that in addition to hitting the 'update' button in the dialog, tabbing thru or using enter to commit the value also be valid methods of committing the tag data.  I know it's a nitpick, but its also an interface behavior standard.

REACT 2 Released

Reply #561
I'm sure I have read the answer to this before, but can't find it again...

I use React2 to rip to FLAC and MP3. Album art is embedded for MP3 files, but for FLAC there is a JPEG created called 'folder'.

SO now you're all shaking your heads because you know what I'm about to ask... and I have mine hung in shame... 

How do I ensure that the album art is named specific to artist/album? Can I embed album art into FLAC files the same as MP3?
I'm presuming that you are using REACT-track.cfg.

If you are embedding the artwork in yor MP3s you should already successfully be embedding it in your FLACs as well.  You could use metaflac, or possibly MP3Tag, to test.

To change the name of the JPEG replace the following line in the FLAC section of the CFG:

Code: [Select]
IF %have_cover%==1 IF NOT EXIST folder.jpg COPY "@cover@" folder.jpg

... with:

Code: [Select]
IF %have_cover%==1 IF NOT EXIST "$artist$ - $album$.jpg" COPY "@cover@" "$artist$ - $album$.jpg"

... or something similar.
I'm on a horse.

REACT 2 Released

Reply #562
Is there a reason that you have to look up the freedbid before ripping begins?  Isn't that when the AMD tags are committed?  Why not use the cfg file to echo any values added into a file named with the freedbid using the output redirect (>) operator - ie echo @freedbid@ > @outroot@\@freedbid@.amd  Following that up with an append operator (>>) for any further metadata for that album.

How does EAC know when to do a compression queue? is that switch accessible to react?
The AMD gets written just prior to ripping by the wrapper instance of REACT, and is read just prior to running the batch file by the processing instance of REACT.  The processing instance is not run until the queue is activated.  The wrapper instance has no access to the @freedbid@ token, as that is part of the processing phase.

It's possible that I could use REACT to check whether the queue is active, but that would involve opening the dialgue and checking the state of the checkbox - yet more screen flickering, time, and risk of going wrong - which is my concern with creating this temporary cuesheet...  it's an idea though.

 
I agree, amending values is probably the right way to do it. I'd also like to recommend that in addition to hitting the 'update' button in the dialog, tabbing thru or using enter to commit the value also be valid methods of committing the tag data.  I know it's a nitpick, but its also an interface behavior standard.
Yes, if it's just updating I am basically planning to turn to simple text boxes - which should hopefully give us normal Windows form behaviour.  AutoIt's GUI authoring is not as good a Visual Studio (I am disappointed that using the keyboard only is not properly supported by the current dialogue).  My intention would be, as soon as a user exists a text box that value would be recorded.
I'm on a horse.

REACT 2 Released

Reply #563
The wrapper instance is very limited in the data it has access to, which is why you would like a command line way of getting the freedbid.  That also brings up the question of what to do if a disc isn't in the freedb database.  It sounds as if we should lobby the EAC developer(s) to make more hooks available since the data is acquired prior to ripping by EAC.  Hmmmm, will have to ponder this.

I've also noticed a weird behavior in REACT - the longer that the program is open and working there builds up a delay between inserting the disc and displaying the track information.  When freshly opened, and a disc is inserted the track data shows up almost immediately after the freedb query is complete.  If REACT has been open several hours it can take 20-30 seconds to show and after a day or so, can be almost a minute.  The workaround has been to periodically restart REACT, but I thought I would share this with you.

REACT 2 Released

Reply #564
If you are embedding the artwork in yor MP3s you should already...


Thanks Synthetic Soul. Now that I have worked it out, I realised that Foobar won't recognise album art unless called 'folder.jpeg', which is why I didn't do it the first time.

Have checked FLAC files with Abander Tag Control, and still no embedded album art. Might have to check with metaflac in case, because if the album art is embedded it should solve all my issues (provided foobar sees it). Strange that it is working for my MP3s coded at the same time though...

Thanks again.

REACT 2 Released

Reply #565
The wrapper instance is very limited in the data it has access to, which is why you would like a command line way of getting the freedbid. That also brings up the question of what to do if a disc isn't in the freedb database. It sounds as if we should lobby the EAC developer(s) to make more hooks available since the data is acquired prior to ripping by EAC.
That's right; it basically has access to the album-level meta data entered in the main EAC GUI (artist, album, date, genre) and the additional meta data (AMD). And thn of course it can execute EAC menu commands to achieve its goals (like creating cuesheets, or starting the rip process).

I don't think it should matter if the disc isn't in the database, there will still be a freedb id (just no matching id in the database).  It would be nice to have an easy way to get the id.

FYI there is another way I found to get the freedb id, which is to export the disc data to a DB text file, ensuring that the settings (freedb / Database options > Export) are such that the freedb id is included.  However, this process is no less simple than creating a cuesheet, and requires that the user's EAC settings are tampered with (and maintained), so I still favour the cuesheet approach.

I've also noticed a weird behavior in REACT - the longer that the program is open and working there builds up a delay between inserting the disc and displaying the track information. When freshly opened, and a disc is inserted the track data shows up almost immediately after the freedb query is complete. If REACT has been open several hours it can take 20-30 seconds to show and after a day or so, can be almost a minute. The workaround has been to periodically restart REACT, but I thought I would share this with you.
IIRC I have heard of other people having problems after running REACT for a while.  I can't think what might be going on; certainly nothing that would make a difference of almost a minute!  I guess AutoIt, or the REACT code, is doing something wrong.
I'm on a horse.

 

REACT 2 Released

Reply #566
Having a problem when creating Various Artists.  The EAClog is not copied to the Music Directories or deleted.  All is great for Single Artists.

I can see the EAClog text file saved as 'Various - $album$.txt' in the Temporary Directory specified in EAC. 
When I debug I see that REACT is looking in the same Temporary Directory but for a file named '$artist$ - $album$.txt' where $artist$ is the artist's name of the final track of the CD.  So REACT states that it can not find the specified file.

What have I done wrong?  I have tried replacing the standard copy with  COPY /Y "C:\Temp Music\Various - $album$.txt$" "Various Artists - $album$ - EAClog.txt"    but with no success.

Any help appreciated.

REACT 2 Released

Reply #567
Here's a hastily bugfixed b16b.

When ripping to tracks the log file was set as "$artist$ - $album$".

IIRC, from past issues with REACT, EAC will not always pass "Various" as the CD artist for VA albums - it depends on the freedb submission.  Sometimes it's "Various", sometimes its "Various Artists" - IIRC the submission has to begin with "Various" for EAC to pick it up as a VA album - users sometimes submit using something else!

EDIT: NB: I Just searched and found the original discussion.  It's pretty convoluted, but documents the time that we discovered how EAC deals with VA freedb entries.

With this in mind this fix grabs the CD Artist from the basename string when dealing with a VA album ripped to tracks - hopefully ensuring that it will match EAC's naming scheme (whether the freedb entry has used "Various", "Various Artists", "Various Artist", or "Various Badgers").

Please let me know how it goes.

NB: I used b16b as I'm part way through b17 (see my post on Aug 10).
I'm on a horse.

REACT 2 Released

Reply #568
Here's a hastily bugfixed b16b.

When ripping to tracks the log file was set as "$artist$ - $album$".

IIRC, from past issues with REACT, EAC will not always pass "Various" as the CD artist for VA albums - it depends on the freedb submission.  Sometimes it's "Various", sometimes its "Various Artists" - IIRC the submission has to begin with "Various" for EAC to pick it up as a VA album - users sometimes submit using something else!  (Just searched and found the original discussion (that is a concluding post, you can read before and after for a greater understanding)).

With this in mind this fix grabs the CD Artist from the basename string when dealing with a VA album ripped to tracks - hopefully ensuring that it will match EAC's naming scheme (whether the freedb entry has used "Various", "Various Artists", "Various Artist", or "Various Badgers").

Please let me know how it goes.

NB: I used b16b as I'm part way through b17 (see my post on Aug 10).


Thanks, I thought I was going mad.  I shall give b16b a try tonight and let you know.

REACT 2 Released

Reply #569
Thanks, I thought I was going mad.  I shall give b16b a try tonight and let you know.
Disclaimer: I cannot promise that REACT 2.0.ssb16b will stop you from going mad.

If you're backing up a large catalogue of CDs you're probably too far gone...
I'm on a horse.

REACT 2 Released

Reply #570
Thanks, I thought I was going mad.  I shall give b16b a try tonight and let you know.
Disclaimer: I cannot promise that REACT 2.0.ssb16b will stop you from going mad.

If you're backing up a large catalogue of CDs you're probably too far gone...


You're probably right, in fact more than probably!!

I tried ssb16b and it did copy the log file and the cover art to the music directory but my (much alterered as I tried to get it to copy the log file last night) REACT-track.cfg copied the log file with the same $artist$ name as the same as the artist name as the final track of the CD and I had cover art for every artist on the CD.

I added the following lines in stead of the standard ones and all appears good.

Code: [Select]
        IF @various@==1 GOTO end_SA_Cover
            IF %have_cover%==1 IF NOT EXIST "$artist$ - $album$ - Cover.jpg" COPY "@cover@" "$artist$ - $album$ - Cover.jpg"
        :end_SA_Cover
        IF @various@==0 GOTO end_VA_Cover
            IF %have_cover%==1 IF NOT EXIST "Various Artists - $album$ - Cover.jpg" COPY "@cover@" "Various Artists - $album$ - Cover.jpg"
        :end_VA_Cover


Code: [Select]
            IF @various@==1 GOTO end_SA_EAClog
                COPY /Y "@eaclog@" "$artist$ - $album$ - EAClog.txt"
            :end_SA_EAClog
            IF @various@==0 GOTO end_VA_EAClog
                COPY /Y "@eaclog@" "Various Artists - $album$ - EAClog.txt"
            :end_VA_EAClog


So I am working now so thanks very much

REACT 2 Released

Reply #571
My brain's a bit fried, and it looks like you're pretty much sorted anyway, but it looks to me like you could simply use $cdartist$ instead of $artist$, with no decision making necessary.  For VA albums $cdartist$ will return the value of the VA variable set in your REACT.ini, which defaults to "Various Artists".

Therefore, for a VA album "$cdartist$ - $album$" should give you "Various Artists - $album$" while a non-VA will still equate to "$artist$ - $album$" (cdartist == artist) .

Code: [Select]
IF %have_cover%==1 IF NOT EXIST "$cdartist$ - $album$ - Cover.jpg" COPY "@cover@" "$cdartist$ - $album$ - Cover.jpg"

Code: [Select]
COPY /Y "@eaclog@" "$cdartist$ - $album$ - EAClog.txt"
I'm on a horse.

REACT 2 Released

Reply #572
My brain's a bit fried, and it looks like you're pretty much sorted anyway, but it looks to me like you could simply use $cdartist$ instead of $artist$, with no decision making necessary.  For VA albums $cdartist$ will return the value of the VA variable set in your REACT.ini, which defaults to "Various Artists".

Therefore, for a VA album "$cdartist$ - $album$" should give you "Various Artists - $album$" while a non-VA will still equate to "$artist$ - $album$" (cdartist == artist) .

Code: [Select]
IF %have_cover%==1 IF NOT EXIST "$cdartist$ - $album$ - Cover.jpg" COPY "@cover@" "$cdartist$ - $album$ - Cover.jpg"

Code: [Select]
COPY /Y "@eaclog@" "$cdartist$ - $album$ - EAClog.txt"


Yeah, I see it now.  I shall change it to cdartist.

REACT 2 Released

Reply #573
I went beack to ssb15... seemed to work better...but still not fully reliable.
I find it hard to believe that b15 should perform any different to b16 - the changes were with the GUI.

Understand, but there it is. I have reason to suspect the GUI is interacting with other windows in various "wait for XYZZY to happen" ways... see below. I'll try ssb17 when it's ready...

Quote
* If I leave DEBUG off, the batch file never runs. Is it possible that with DEBUG=1 in the ini file, something inside REACT changes?
I would have said that it does run, but exits so fast you don't see it.  Just a guess.

Nope. The batch file *hangs*. I should not have said "never runs". I mean, it opens, and hangs immediately.

ANYway... I've been running for a while now, on my patched ssb15, and have learned some things. I found workarounds for everything until now...

1) If I begin an F10 whole-disk capture (I'm capturing single-file FLAC plus multi-file MP3), and then something goes wrong so I have to cancel:
  a) If I cancel during gap-finding, I can restart with no problem
  b) If I cancel later, I need to restart REACT

2) After performing several rips, the albumart software does not fire up the first time I press F10. If I wait for the gap-find to complete, wait another minute or two, then press F10 again, it goes forward. I think this relates to the comment elsewhere in this thread about REACT slowing down after many rips.

  a) Idea: could it be NOT fully resetting after the CD is removed and/or while firing up the next Rip? I'm guessing that something is waiting for a window to complete or close or ???

  b) It would help to have a keystroke that does a "full reset-- restart REACT as if just opened"... for those strange error situations

3) It's not clear to me what REACT knows or does with respect to the AccurateRip database, and/or when a rip is unsuccessful.

QUESTIONS:
  - How does REACT decide whether a RIP was completed successfully?
    a) If I stop the RIP, I want REACT to not-process
    b) If I let the RIP complete, if REACT thinks there was a problem, it should ask me about continuing, rather than auto-killing. It is hard for REACT to know for sure if things worked or not!
        - on a C2 drive like mine, "timing error" is not a problem, usually... just means some retries happened
        - it's possible to have AccurateRip tell me the rip was "bad" when it isn't. I just ripped a CD that's perfect, but it's a different pressing than the 2 copies in the DB. It worked, but AccurateRip doesn't know that.
    c) In the case of this good-but-AR-thinks-not, I get the following result
        - Full rip to wav
        - REACT skips making the FLAC file
        - But the MP3 files ARE created
        - I get no indication of error or trouble... just missing flac file(s)!

Your thoughts on this last one especially appreciated. I can't get REACT to make the flac file! No error messages, it just doesn't do it.

Thanks muchly,
MrPete

REACT 2 Released

Reply #574
Thought i'd report that React 2 16b + EAC0.99pb3 & Accuraterip + Album Art Downloader 0.8 all seems to work together just fine ripping to Wavpack and mp3.

Thanks to all thats made this possible.

 
SimplePortal 1.0.0 RC1 © 2008-2021