Another computer question...

I think I did look into it ages ago but I couldn’t see any advantage over the Borland C++ Builder I have.
What you have is perfectly adequate for things like the above. I used to use 3.1 a bit before going back to M$. Visual Studio 2013 Express is free of any licen(c|s)e hassles (although M$ probably make you jump through hoops to download it now), and works on 32 bit machines.
 
Why is there no simple straight-forward command-line C compiler for Windows (that I could find)? Not even Gnu seems to have been ported. Is there some impediment I don't know about? Is it simply that anything without an IDE is too antiquated for words (or Windows!)? I'm starting to wonder whether my old Modula-2 compiler will still work...
 
Why is there no simple straight-forward command-line C compiler for Windows (that I could find)?
I think I looked for an alternative command-line C compiler once. I already had an ancient version of Turbo C, but that only produced 16-bit code. I seem to recall it could only cope with 1MB of data (sounds low, but it was for DOS rather than Windows) and it required you to go through hoops to access all the memory. Anyway, couldn't find one. I think the version of Borland C++ Builder I used comes with a command-line compiler. It's possible that the free compiler Martin referenced would do as well - (Turbo C, Borland C++ are from the same supplier and became branded Embarcadero c2009)
Is it simply that anything without an IDE is too antiquated for words (or Windows!)?
Probably. Anything without an IDE or that can be used without the IDE could be 16-bit, maybe 32-bit but unlikely to be 64-bit.
Never used it. But gather it was developed by a well known quiche eater Niklaus Wirth. ( https://www.ee.ryerson.ca/~elf/hack/realmen.html )
 
Oooh... Thanks! I'll give it a go and report back.
@EEPhil
Sorry to report id3genre.exe returned no output on 3 .mp3s out of a sample of 10 (score 7/10). Also, the example contents for a .bat only works with .mp3s in the same folder - there is no path passed to the invocation of id3genre, so despite the "-r" in the for loop, recursive search does not work. I tried using "%%~fg" (with the speech marks, to cope with spaces in the path), but that didn't work either so I guess id3genre is written to expect a filename only. (Sorry, I confused /r with /R)

@Allotment
Using the same test as above (just substituting the .exe) scored 10/10! You win, well done. I guess that means my spec is OK, it must be EEPhil's coding ;). But why is your .exe 1.7MB when EEPhil's is a mere 60K (that it doesn't work notwithstanding)??? There must be a load of unnecessary garbage rolled in by the compiler.

Don't take me as ungrateful for both your efforts, and I am particularly pleased to have EEPhil's source code to study, but I'm sure you wanted the feedback.
 
Last edited:
Sorry to report id3genre.exe returned no output on 3 .mp3s out of a sample of 10 (score 7/10). Also, the example contents for a .bat only works with .mp3s in the same folder
Just for my benefit can you let me have some idea as to what the difference is between those that work and those that don’t. I’ve obviously boobed somewhere and I’d like to understand why. (Are your files big? Would you be prepared to somehow send them to me if they are not too big?)
The batch file was for my own use to test the few files I had - it was intended to work in the current directory. Perhaps I misunderstood your spec.
Having revisited the C source I’d be tempted to rewrite one of the functions to trap a possible pointer error.
 
Today's conundrum: using a Lightning-to-USB adapter, I can "see" files on a powered external HDD from my iPad... but not write to it. Is that because iOS (like Humax) can't write to NTFS?
I use the "FE File Explorer" app, and move files around by SMB. FE can see into Files and Camera Roll, connect to any network storage available, and even USB (Lightning) connected storage. As above, it won't write to the (NTFS) USB drive though.

The reason I want to write by USB drive is for speed to make a bulk copy of my camera roll.
Maybe try using reformatting drive to FAT32 or ExFAT?
FAT32 is older and may have better support, but has 4GB file size limit. As it is for camera roll - that may be ok.
ExFAT is newer so may be less widespread use but does not have the 4GB file size limitation.

:rolling:
Non-destructively?
I didn't realise you were against a re-format (eg after backup and restore). I thought doing that will produce a drive that you can use between your iPad and other device you used to write to the NTFS drive.
So how did you get the iPad to write to your NTFS drive? Eg is it a case of purchasing a NTFS driver from the AppStore?
 
Last edited:
I didn't realise you were against a re-format
It happens to be a big archival desktop drive with stuff already on it.

So how did you get the iPad to write to your NTFS drive?
Where did I say I had? I'll fish through my USB drives to see whether I have one that is FAT or can be transmogrified to FAT, just to establish the truth of the matter, but I suspect this is an NTFS compatibility issue. Network access by SMB is format-agnostic (the remote SMB server handles all that, SMB operates at the file rather than the file system level).

The amount of data was queried at one point: I think my camera roll is about 100GB, and includes a lot of video. I don't fancy transferring that by WiFi!
 
Just for my benefit can you let me have some idea as to what the difference is between those that work and those that don’t. I’ve obviously boobed somewhere and I’d like to understand why. (Are your files big? Would you be prepared to somehow send them to me if they are not too big?)
No problem, you only need to parse the ID3 part of the file, so I could crop out the MP3 payload and PM them.

The batch file was for my own use to test the few files I had - it was intended to work in the current directory.
My mistake, I confused /r with /R. You are correct. This works:
Code:
echo off
for /R %%g in (*.mp3) do (
  echo %%~nxg
  id3genre "%%~fg"
)
(but it works with Allotment's exe better than with EEPhil's exe.)

Can anyone think of a way to echo the filename and the output of id3genre on the same output line?
 
Last edited:
Can anyone think of a way to echo the filename and the output of id3genre on the same output line?
Definitely not possible at the moment, id3genre outputs to the console but apparently not by stout or sterror. I've tried redirecting both to file, but the output remains resolutely to console!
 
The easiest way to get the file name and genre on the same line would be to include it in the program via a switch. Which version of id3genre isn’t writing to stout, mine or Allotment’s?
Re: samples. Yes just the first few seconds of a track with the ID3 data should be sufficient. (A very small amount of payload may help) At least one that works and one that doesn’t- although all samples would be helpful if that isn’t too much trouble - the original (unedited) file sizes would also be useful.
 
Allotment's version outputs to stout, and is redirectable.

Re: samples. Yes just the first few seconds of a track with the ID3 data should be sufficient.
I've replaced the payload with 10 seconds of silence... but in the process something has broken (not with the mp3 files, but the system no longer behaves properly even with the original files). No time to find out why right now.
 
Definitely not possible at the moment, id3genre outputs to the console but apparently not by stout or sterror. I've tried redirecting both to file, but the output remains resolutely to console!

Pleased to see that it worked though I can't take credit, as mentioned I simply wrapped an existing ID3 source library. For info, it should handle almost any flavour of id3.

Adding filename to the output would be trivial. How do you want it separated, space, tab, comma? Do you want filename or full filepath? Similarly is there anything else that you'd like on the same line?

Would it help if it took a path as input and then walked through the disc/directory/sub directories processing all files? If so how would you like the output sorted?

Once you have the output list of files is there any subsequent processing that might (no promises) be automated?

Regarding the size vs eePhil there are two main reasons. I used the GO language which carries a runtime in the exe and adding to that the id3 library that I wrapped is very comrehensive and consequently much bigger, its full of functionality that you wont be using. I could have stripped out the excess function but that seemed like a lot of work and had the potential of introducing error.
 
Allotment's version outputs to stout, and is redirectable.


I've replaced the payload with 10 seconds of silence... but in the process something has broken (not with the mp3 files, but the system no longer behaves properly even with the original files). No time to find out why right now.
Okay. You have a solution and explanation for the size difference. We could leave it at that but my curiosity has got the better of me. Any help understanding where I’ve gone wrong would be appreciated, but I’m not going to lose sleep over it. One unmolested failing file would help. Otherwise I’ll have to file it back in the pending bin.
I do know why my version isn’t redirectable. I suspected that the Go program used a built in library. I probably could have gone the same route if I could have found a third party library.
 
The most likely problem is I’ve made a dog’s breakfast out of it. There could be something different about the failing files which messes up BH’s algorithm - but that’s wishful thinking on my part. :)
 
Why is there no simple straight-forward command-line C compiler for Windows (that I could find)? Not even Gnu seems to have been ported. Is there some impediment I don't know about? Is it simply that anything without an IDE is too antiquated for words (or Windows!)? I'm starting to wonder whether my old Modula-2 compiler will still work...
I used the 32 bit version of this about 15 years ago to build the Windows version of humaxrw.
Edit: Actually this one looks more like the Windows port of gcc. https://sourceforge.net/projects/mingw/ or https://osdn.net/projects/mingw/
 
Last edited:
Okay, a bit weird, something corrupts the console - maybe a control code being output... but it doesn't happen every time. Anyway, package being sent...
 
Okay, a bit weird, something corrupts the console - maybe a control code being output... but it doesn't happen every time. Anyway, package being sent...
If that's me again - the only things that should be outputted are printable characters (in the program isprint(ch)) and cr/lf (maybe also null). Very weird!
 
The most likely problem is I’ve made a dog’s breakfast out of it. There could be something different about the failing files which messes up BH’s algorithm - but that’s wishful thinking on my part. :)
Yes it was me. There is something different about the failing files - they have large frames associated with one of the ID3 tags (COMM mostly). Having ballsed up the way I calculated the size the larger frame broke the calculation. Mea culpa. :(
 
Back
Top