False positive. Here's the scan result by virusscan.jotti.org:

File: REACT.exe
Status: POSSIBLY INFECTED/MALWARE (Note: this file was only classified as malware by scanners known to generate more false positives than the average scanner. Do not consider these results definately accurate. Also, because of this, results of this scan will not be recorded in the database.)
MD5: 4db906bddccb0cd925306e252f746864
Packers detected: PE_PATCH.UPX, UPX
Bit9 reports: File not found

Scanner results
Scan taken on 14 Jan 2008 23:37:27 (GMT)
A-Squared Found nothing
AntiVir Found nothing
ArcaVir Found nothing
Avast Found Win32:Trojan-gen {UPX}
AVG Antivirus Found nothing
BitDefender Found nothing
ClamAV Found nothing
CPsecure Found nothing
Dr.Web Found nothing
F-Prot Antivirus Found nothing
F-Secure Anti-Virus Found nothing
Fortinet Found nothing
Ikarus Found nothing
Kaspersky Anti-Virus Found nothing
NOD32 Found nothing
Norman Virus Control Found nothing
Panda Antivirus Found nothing
Rising Antivirus Found nothing
Sophos Antivirus Found nothing
VirusBuster Found nothing
VBA32 Found nothing


You want only FLAC image & AAC tracks? You only need to edit the INI file:

1. Change "ImageExt=wav" to "ImageExt=flac" (without quotes)
2. Set "NeroAac=0" OR "iTunesAac=0" (I don't know which one you would like) setting to =1 (others to 0 of course)
3. Rip with F10

All this information is available in the original REACT Wiki page.

Is there anyway to embed artwork to .ogg files in REACT? I can do it manually with AudioShell. I have searched, but cannot find a way to do it with REACT.

I don't know of any command line tools to add album art to APE tags (TAK and WV) or to add to vorbis comments (OGG)... I'd love to know myself.


As for the virus report, if you got the .exe straight from Neil's website, I'm sure it's a false positive. If you are worried you can even compile the .exe yourself if you'd like

You could quite easily do this in one stage with REACT.

Keeping the WAV image is easy. The only slightly complicated bit is ensuring that you have an accurate cuesheet for the WAVE file. I would use SED for this: to amend the FLAC cuesheet, and save it in your WAV folder. Here's how:

Assuming that you are using the amended CFGs, replace the section (at the beginning of the image processing code):


.. with this:


Then simply add a line in REACT.ini, under the [UserOutputNames] section, to set the value of ImageDir_WAV.

This additional code will create the folder that you specify with ImageDir_WAV. It will then copy the source WAVE image to this folder, using the same naming scheme as your FLAC image ("<imageName>"). It will copy the EAC log to the folder naming it as "<imageName>.log". Finally it will use SED to replace ".flac" with ".wav" in the cuesheet text, and save it as "<imageName>.cue".

Check this wiki article to find out where to get SED and what to do with it.

I like your SED methodology on the wiki page, but I think I had ran into a problem with a similar methodology when trying to accomplish the same effect myself...

If there is an Ampersand in the resultant %TrackName%, doesn't sed replace it with the matched string? Or does your method somehow avoid that pitfall? I wasn't able to find a method to escape the ampersand within SED, as it didn't except \Q...\E regex within the RHS.

No, my method does not escape potentially problematic characters; so, you're right: it's possible that some filenames may cause a problem.

I guess with some effort we could escape characters before adding them to the SED command. I hate doing this sort of thing in batch files though: the commands aren't really up to it.

Edit: @feelgood, BTW: the potential issue discussed does not affect the code above - only the code in the wiki article. Fear not!

I've certainly noticed this.

I was pondering at one point if I shouldn't just replace the whole DOS backend with a BASH one instead...

Maybe for this summer's "I'm Bored" project?

I don't think there are any other problematic characters, though. I believe the RHS only interprits Ampersands (Matched strings), backslashes and forward slashes. The latter two which should not be in %TrackName% anyway.

Edit: Whoops! Didn't mean to start a fear campaign. Fear not indeed!

Thought it took me to the last page just now... sorry for the late reply.

FEAR NOT! I'm working on the SED problem right now.. actually have been couple of days already.. it's not easy but I think I got it figured out. There's more problematic chars besides the ampersand. I've gathered all the information and now I'm testing and creating escape code. I'll get back in 1-2 days (I can't use all my time to do these things u know).

The SED tool is a bad choice (in case there's more options to choose from) for "REACT:Amending Cuesheet File References" because there's no need to use regex in the substitution. If anyone knows a good DOS command line utility to just change strings in text files, let me know. It would be much easier to use without these regex special char escapes. It's impossible to write a "definitive" escape guide (or code) to SED since there's a few "what if user decides to do.." options.

And for the cherry on the top: SED converts all modified/created files into unix-type newline files (CR/LF -> LF). Files work ok in windows but... devil in the details kind of thing. I had to get a new tool (todos.exe) to change SED modified files back to CR/LF.

GSAR: http://gnuwin32.sourceforge.net/packages/gsar.htm


Neither solution discussed today require regular expressions. GSAR would require some extra coding to create the list of commands to execute, as it can't appear to run a list of actions from a text file as per SED; however I would assume that you could simply write GSAR commands to a batch file instead, and just execute it (rather than write SED actions to a text file and pass it to SED).


As an example, the SED line above:


.. could be amended to:

This would be my suggestion for the cuesheet amend code:

Use the following in the track processing section:


E.g.:



Use the following in the final track section:


E.g.:


If anyone wants to test and confirm we could add it to the wiki article.

I can do it. I have already done some test code but just need to finish it later (I'm watching a hockey game currently).

I don't think you can escape quotes with "".

Here's my test (for general use):

In general we need to escape two chars: the quote (") and the colon (:). The quote is escaped with hex (" -> :x22). I know that we don't need these escapes with "Amending Cuesheet File References", but I think that it would be better to include these (+text to explain them) because somebody could use GSAR to other needs.

Also I found this in the manual:

So if you let me, I can change the wiki page later today. ok?

The code I posted has been tested, and works.

I'm not sure that it should be included in that wiki article, but some tips for using GSAR elsewhere would always be useful.

Synthetic Soul, you're the man! This worked perfectly!

Now, after ripping the CD (F10) and virtual-ripping the wav image-file (F4) I have:
1. FLAC-image and
2. iTunes AAC-tracks with all the appropriate cue and log files. I even get
3. the original WAV image-file and cuesheet to burn a backup copy of a badly scratched disc, if needed.

Thousand thanks!

SamHain86 and Akkurat:
React/iTunesEncode don't support one-pass conversion of FLAC-image and iTunes AAC-tracks. That should be added to the Wiki.

- feelgood

We were both right (if we count out my bad expression I made in a hurry): one can't _replace_ (this is what I meant) the quote with two quotes but three quotes.. quite confusing since the colon is escaped with replacing it with two colons. I would use the hex or decimal escape solution. But in fact we don't need that in "Amending Cuesheet..." because we can shorten the substitution to:




Any suggestions where? I think I'd put that in the "Amending Cuesheet..." wiki article since this is the only place where it's going to be used... BUT in the bottom part of the page with big header separating it from the main article. No?

I believe that I had the additional text to ensure that the right part was being acted upon; however, it should be reasonably safe to cut the text down to the above.

I totally agree. In retrospect the article is an acceptable place, if the additional code is added as an extra section at the bottom, as supplimentary information to the actual article text.

Thanks.

So is

The final verdict?

If Akkurat thinks it works then I guess I'm inclined to believe, since he tests everything so meticulously

That's my trademark. Pain in the ass. I vote yes.. would you believe?! But seriously, is there a possibility to find more than one identical "$cdartist$ - $album$ - $track$ - $title$" text strings in cue file? No. At least the $track$ is always different. The "FILE "" string at the front makes no difference whatsoever.

The work is a little bit stopped because, can you already guess, I think I've found a bug/problem in GSAR (I emailed authors). Whatever I do, I find problems... I don't know if I should laugh or cry. Get this; I still don't have my custom working REACT configured.. all I seem to do is bug hunt... I implemented tag.exe to my conf and found a bug/problem, fixed it, next SED amend cuesheets, major problems.. maybe I have my REACT working in the next century.

Anyone care to try following instructions with GSAR?

This always gives me the following error message: "gsar: command error, no search string specified".

Um... I am not quite sure what you mean... Is that because iTunesEncode does not support piping?

I use my REACT2 to rip a CD to a FLAC-image [with embedded CUE-sheet] AND create MP3 and OGG Tracks in one pass. Image mode can process the WAV and CUE to create the tracks using ACDir.

My string will work absolutely fine (whatever Akkurat's concerns) but the above should be perfectly adequate, and I would second it for the sake of clarity.

BTW: It took me five minutes of Googling to settle on GSAR.

Can you share what the problem is?

I think his issue is that he cannot get it to execute a script from file.

Correct. I'm sorry, I'm sometimes completely fu#%ing useless at communicating. It was clear to me that everybody would understand that the last request to test GSAR instructions I posted is the bug/problem I encountered. Sorry. *crawling back under my rock*


Yes it works, I just offered a replacement so that we could get away from the confusing char escape.. as you say, for the sake of clarity.

I don't know for sure, but there is some discussion in this thread beginning from post #167.

- feelgood

(and I sure feel good now, thanks to this magnificent forum!)

No, that's fine, no doubt me being dumb.

I think I was probably confused as I didn't see it as being a very useful feature, and therefore not a showstopper for GSAR. I'm glad to hear that it's not to do with the core functionality anyway. I think GSAR could be useful for some other actions in REACT configs.

Looking at the original REACT-image.cfg, there is no itune track setup. However:

• there is the Nero AAC encoder; is there is big difference? They both use M4A
• Would you be against using MP3?

Another idea for you is to use FB2K to transcode your FLAC-image configured with the iTunes AAC encoder, saving the time to mount a WAV image. Also, provided iTunes M4A allows it, it will keep all your tags, image art, and put the embedded EAC log into the M4A files you make.

If you need to use iTunes AAC, you could just split the wav image into multiple wav files, and then encode them one-at-a-time much like the TAK processing does. No piped input required.

Though I don't fully comprehend the problem at hand, so maybe this isn't a very useful suggestion.

In my images.cfg, I added something like this:



It's late and I might have missed a few things, but I tried to hurriedly take out code that is specific to my custom configs/ini. But you should get the concept. I use NeroAacTag to add some additional tags that iTunesEncode doesn't let you add, but they're not important and get skipped if NeroAacTag isn't found. oh well.
It's been tested lightly, but not extensively. Also note that I use a lot of crazy variables not present in standard REACT, such as %log% (use @eaclog@), %cue% (use $albumfile$.[mg].cue) and some things like %have_log%, @makem3u_aac@ ... etc etc etc. But the core concept should be the same.

Just tried this out and no dice. The WAVs were extracted however no M4As created.

I'll try this again after work.

-

I do not see how this can work. You are using ACDIR on individual files but import the same source cuesheet. Wouldn't that source CUE point towards the WAV-image?

Can I get something cleared up in my mind? Are you using GSAR in place of SED because SED does not handle certain characters well ('&' now that it can be included in track titles for example)?

Yes.

Although SED is far more flexible than GSAR, it's complexity is not required for the solutions suggested so far, including the cuesheet amending that we worked on.

As SED could potentially cause problems with a few characters it seems safer to change to GSAR, which will do the job just as well, but should not be affected (so much*) by these issues.

I suggested SED when you first asked about editing the cuesheet, as it was the only command line F'n'R tool that I knew of. Until yesterday, when nago highlighted that ampersands could cause an issue with SED, I was blissfully unaware. I Googled about and came across GSAR as an alternative. As it was another GNU tool - which I rate - I stopped searching any further; however, it is possible that there are even better options (that perhaps have some of the benefits of SED that the simplistic GSAR does not) out there.

* Akkurat is discussing the necessity to escape double quotes and colons for GSAR strings. As neither can be used in filenames, these are not an issue for the cuesheet filename amending.

Edit: BTW, I would suggest, when the wiki article is updated, that the SED-specific text is kept, under a "Using SED" subtitle, with the GSAR text added above that section, under a "Using GSAR" subtitle. The opening passage of the article should then highlight that the GSAR approach is recommended. I would like to keep the SED text for reference, and it may still be useful to some people.

I have made some amendments myself.

While updating the wiki I have realised why I may have used the full text. If updating an MP3 cuesheet it is necessary to amend the file type from WAVE to MP3, as so:

I'm currently discussing the problem with the author. If the thing gets resolved, should we update the amending cuesheet wiki to use that feature? IMHO it's nicer way to do things but it's obsolete since there's already a working solution.


It's more than that ampersand character. Mainly the opening square bracket ( [ ) + other characters which have special meanings in the regex (basic/extended). The square bracket is used in ImageNaming INI variable AND also in the various artists filename scheme.


I have to disagree slightly. The SED instructions should be removed since it's very risky to use it now without char escapes (or instructions how to do it). Maybe reference to SED should be left but without any code/instructions to use it AND a warning for the users who are currently using SED...?

Also I would recommend every SED user to check their cuefiles because there's a very high chance that your cuefiles are corrupted!!

Edit: Do I take it from your enthusiasm for this approach that you can have multiple occurences of the -s and -r switches in a file? If not then I am still finding it difficult to see the appeal.

The ampersand is the only character that will cause a problem in the right side of the expression, and that was the character that nago raised to make me aware of the issue.

Your work on escaping for GSAR and SED would certainly be a useful addition to the wiki article.

Then I guess we'll have to agree to disagree.

lipidicman should be able to respond well to this: presumably he must have many cuesheets amended using the SED technique. Perhaps he would be so good as to check a selection, or even upload a zip file with a load of cuesheets for testing.

Edit: I'm not really sure what you mean by corrupted. I can see that converting "/r/n" (CRLF) to "/n" (LF/newline) is a change, but any text editor worth its salt can open UNIX-style text files, and foobar has no problem with them. That just leaves a handful of cuesheets that may be screwed due to unescaped characters on the left hand side (@basename@), or the ampersand on the right (%TrackName%).

I agree that it would be better for none of this to occur, but stating that "there's a very high chance that your cuefiles are corrupted!!" is a little melodramatic don't you think?

The good news of course is that GSAR has the ability to convert UNIX ASCII text files to DOS ASCII text files.

Yes, just like the SED works: one txt file and one gsar command to run all... IF I'm not mistaken.


I don't know why you're so defensive. If you read my comment again you should see that I was talking about the whole sed command, not just the "right side". My motive was merely to pass on information to this subject which was not discussed here before. Nothing personal.


So if I change the wiki, you would revert it back?


No, I don't think so. Why do you like to play down this issue? And forget about the CRLF issue, that was not in my mind when I wrote my warning.

My (currently incomplete) collection produces:

Of course this doesn't count total possible corrupted cuefiles because there can be several filenames w/ ampersand in the filename per directory/album/cuefile. But still. Usually fail rates are counted in "nines": 99,99...% if that kind of thinking/measuring can be adjusted to this issue. Also these figures from my collection lacks the various artists filename scheme square brackets because when I ripped these mp3's, I was unaware of REACT.

EDIT: these figures doesn't count the other possible problems caused by unescaped regex chars in the "left side".


Yes but it's not needed because gsar doesn't change the "newlines".

That would be good. If that is the case I would probably be up for amending the code.

I know. And I in turn was just pointing out that the reason I only mentioned the ampersand was that was the character that initially highlighted the issue to me. I also pointed out that it is the only character that will cause an issue on the RHS. It's all about informing the reader. You had previously stated that you had discovered other characters in testing (post #1009) - it didn't need re-stating - just as I shouldn't have to re-state my reasoning.

Who knows. Perhaps we should let some other users give their opinion.

I see no reason to totally remove the text, if we keep the opening text that explains that GSAR is the recomended option, and hopefully expand it, with your help, to explicitly state why SED is not the preferred option. Let the user decide which they use, with all the facts in the open. Why not keep it?

Hmm. Seeing as I am the one who posted a resolve to the issue, hours within finding out about it, I hardly think that it is fair to say that I am not addressing it. I would have said that I am the furthest person that you can accuse of that - at least I'm posting solutions.

I agree that 5% is a poor fail rate; however, as you say, if the ampersand is in the artist or album title, the actual number of cuesheets affected could be a lot smaller percentage.

However it may be useful to fix all those cuesheets corrupted by SED.

Oh, I forgot about escaping characters on the LHS.

I believe you can use \Q@basename@\E to solve this issue just fine. Quoting the RHS in SED still remains an issue though.

Still, if you intend to keep the sed instructions on the wiki, this could make a useful amendment.

A prime example of why the SED text should be kept. None of us are SED experts, and the code can always be improved.

Thanks for the input nago. I'll have to read up on those.

Escaping the ampersand on the right hand side shouldn't really be too much of an issue. I think something simple like:

I forgot to mention; I use a %Disc_iTunesAAC_acdir% variable in the encoding string, which gives relevant disc information if need be. The lack of this variable being set could cause DOS to crash, and not encode the files.



At the top where discname stuff is set.

I've tried this, with no success. Is it possible that these is a Perl-only switches? I seem to remember seeing that there are different versions of SED; maybe I need an alternative version? Maybe I'm just being a dimwit.

Maybe I'm the dimwit? I seem to recall using it with some success, but maybe it was a fluke o_O
Or my memory has gone...
Oh well!

The only rational solution is to change my name and disappear from the internet.

Goodbye!

Where did you find that information? Could you post a link to it? Thanks.

EDIT: oops, I saw your last post too late... still the link would be interesting.

And if you're keen on keeping the SED in the wiki as a tool which can be used to other things, may I suggest that you take into consideration the other (maybe rare but still) "right side" can-be-a-problem-things? http://sed.sourceforge.net/sedfaq3.html#s3.1.2

You can run, but you can't hide.

Goodness: "Is it possible that these is a Perl-only switches?"? I think we've found our dimwit.

I thnk this covers it:

I'm not going to answer to the other points since those again turned into a stupid time wasting fight (more or less) about who said what and why, who was right and wrong, who was fast posting solutions and who was not because more thorough testing, yadayada, blahblah, and so on. (I know that this is a rant but I needed to get this out of the system.. better this than continuing the seemingly never-ending bickering. I do apologize for participating in such a conversation again.) If there's a topic somebody would like me to answer, please ask because I'm going to fade to the background again, thanks.


No go. This is what the author wrote: "When gsar became a win32 app the @ support went away. It was only supported using the Zortech compiler.". The following explains more why I thought that it was a bug: "I thought I had removed the @ from the text files but it seems as if this was not the case. Anyway take it from me that @ is long gone.". And why it was removed: "The @ is not really needed anymore on Win32 due to the length of the command line.". So the current solution is the best we can do with GSAR.

Will you be sharing your work with regard to escaping characters for SED?

That is a shame, it would have been tidier. Thanks for the info.

Unfortunately my work is incomplete and rather in a such state that I would have to clean up and make it clearer for others to read.. takes time and since I'm not going to use SED and I still would like to remove SED from the wiki, I'd like to save that time which I see useless. But you never know, now we have to concentrate on the problem with GSAR (check bottom of this post).

Here's a new point of view to the SED & GSAR (if we end up using it) wiki issue: what is the user motive to go to "Amending Cuesheet..." wiki page? What do they want? They want to amend cuesheet file references! I bet that they don't care how it's done and with what new tool.. as long as it's a working solution. Why make it even more difficult with providing options which have the SAME end situation; amended cuesheet file references? I bet that the already steep learning curve to use REACT is holding back the popularity of this program.


Well, it might have been the solution we NEED if we are going to use GSAR.

Houston, we have a problem.

update-cuesheet.bat:

Executing (execution to us):

When I copy&paste the code from the update-cuesheet.bat file to the command prompt and push ENTER, it works.

Two things to notice:

1. all chars between % chars are removed (+ % chars)
2. pay attention to "special" chars (é^%&--x'[]!äöå <-----> Ú^&---'[]-õ÷Õ)

The % char problem is easily avoided by escaping % with %%. But what to do with the changing chars?

I have the feeling that the dropped out @ functionality would have worked perfectly to us.

So is it a time to try out a new tool?

Trust you, eh?

Hmm.. does this mean that GSAR can't handle anything more than basic ANSI? I must admit that I get very confused about codepages etc., as I am a simple English speaker who listens to UK/US music on the whole (Air is one exception that I can think of). It appers to me to be a codepage issue of some sort or another, but that's as far as I know.

As you say, the % issue isn't a huge problem - something I should have thought about before - but something that we can deal with.

Well, in answer to your question: I'm fine about switching to another app, as long as it is free, and does the job! Any suggestions?

Try copying the Codepage Change command into the bat file you are calling-- the one present at the top of both images-cfg and tracks-cfg. Tycho had a reason for putting it in there, it might benefit your child process.

Just a thought!

And what a thought it was, it worked! I'm too shit with codepages, character sets, etc. and I don't understand how this thing works but it works. It's really strange; the command which is run contains wrong chars but it still changes them to correct ones in the output file. Go figure.

BUT, again, I spoke too hastily, I don't know a way to escape % chars in batch variables. Now I remember that I have tried this many times with no luck (last I tried it with the playlist generation problem which I solved in other way (look in the Creating A Playlist wiki)). In fact, with little googling, I think it's impossible.. at least with the following normal escape solution:

Any hints to solve this? I wonder what IS the next problem after we solve this one.

These problems have made me consider writing a console app (unfortunately it would .NET as I'm not up to it in C) which sole purpose is to take a string and escape it using a specified method.

A more flexible alternative, but possibly more effort for the user, may be to use a WSH script (VBScript for me), run using CSCRIPT.

Either way though, it's just confusing the solution further and further, although it would hopefully result in a complete working solution.

Edit: Hang on. If the % is an issue for GSAR, wouldn't it be an issue for every app used in the config? Is there not already something in place in the code that deals with this? I'm off to bed, so can't test now.

Edit 2: Just checked the source. Most tokens are replaced using fStringReplaceForDOS(), which escapes %. Can someone test with REACT. G'night.