Another computer question...

EEPhil said:
Think COMM is full of text, so probably not.
Click to expand...
Not a very large frame then, I presumed you were talking about something bigger. Some of my "massaged" test files are larger than others and I wasn't sure why, I assumed they contained larger cover art tags (size, resolution, detail, compression). Your v2 fixes it, thanks very much.

I'm not ungrateful to Allotment for his contribution, but at 60KB vs. 1.7MB and editable source code to boot, in this instance there's no contest. However, I suspect Allotment's packaged standard library will work in more situations than EEPhil's bespoke special-to-purpose.
 
Black Hole said:
Not a very large frame then, I
Click to expand...
No. In most cases I’ve seen the frame size is 4 bytes (0,0,0,X) where X was less than 127. I spotted the fail when X was c180 which immediately gave me the clue to the signed/unsigned problem. Novice mistake and I should have known better.
 
Black Hole said:
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...
Click to expand...
I was thinking about this, and about to search though my archive for Modula-2 stuff, when a brief Web search came up with the site modula2.org complete with freeware downloadable Win32/64 development environment. Even a quick glance at some code examples shows why I liked it at the time: very clean and readable.

Is there a reason I should get into C rather than renew interest in Modula-2?
  • More portable;
  • More applicable to working with RPi and Linux
...but on the other hand, if there's no easy route into C on Windows/DOS (xyz321's comments above not withstanding – I haven't investigated yet), why should I bother? It kind of doesn't really matter what language I code in (on the rare occasions I need to), I can't remember the details from occasion to occasion so I have to follow examples of existing code (very easy now everything is available on the Web).

If I were drawing on personal long-term experience that would be BASIC, Z80 Assembler, Forth, and Awk. The most difficult bit is always access to external functions (be those libraries or OS calls).
 
Unless you want a challenge, I would stick with the programming you know. Especially true if you only program occasionally and have limited time/interest.
In my opinion C isn't that portable. (A colleague described C as a write only language, once you've written a program it's a sod to come back to it, read it, and understand it). I tried running the id3genre program above on a VAX simulation (OpenVMS, not a vacuum cleaner or vaccination) and it didn't work. It would require more effort than I'm prepared to give it to make it work.
Although my Pascal knowledge is ancient, I can see how id3genre could have been written in that. A brief glance at Modula-2 suggests there is some similarity between that and Pascal. So maybe that kind of program could have been written in Modula-2. :unsure: Not sure of the portability.
Not sure Basic and Forth would do the job. You have already pointed out in this thread a problem with Awk and extracting the genre.
Black Hole said:
I can't remember the details from occasion to occasion so I have to follow examples of existing code (very easy now everything is available on the Web).
Click to expand...
Neither can I. But then I never could. I have C, Pascal and Fortran books to hand. I use the Web frequently when programming in Java.

(Edits in this because browser slowed to a crawl during writing.)
 
Last edited:
EEPhil said:
Not sure Basic and Forth would do the job.
Click to expand...
It depends on file IO support (for this job in particular, not necessarily all jobs in general), I'm sure they could in a fashion (some kind of modern implementation of BASIC anyway). I haven't touched it in decades, but as I used BASIC at school (on a teletype linked by phone line to the local Electricity Board mainframe/mini), and at Uni (on a teletype directly connected to a PDP8 (IIRC), and is very readable, it is both ingrained and also easy to pick up. I am perplexed that it seems less popular these days.

Forth can do anything if you work hard enough at it, and there are some spectacular implementations for modern Windows. That doesn't mean it is best suited to file processing, which Awk is superb for (provided the data is pure text not binary!). I find it perfect for robotics. Nonetheless, with a sufficient appreciation of how Forth works under the hood, custom data structures could provide direct access to the ID3 tags. I might try that (one day, when the fancy takes me).
 
I agree with EEPhil (#148 above), for occasional use and while it meets your needs then stick with what you know. Once you have a working application using familiar tools then that would be the time to evaluate the merits and defects of alternative approaches.
 
Allotment said:
Once you have a working application using familiar tools then that would be the time to evaluate the merits and defects of alternative approaches.
Click to expand...
The difficulty is the reverse. If you have the a working program written in an unfamiliar language - do you learn that language and acquire a compiler or do you convert the the program into a language you understand? A moot point if you can't obtain a compiler.
 
There's an IT addage that's around in many flavours, something like "make it work, make it right, make it fast" Make it work is obvious. For make it right you might want elegant, simple, or portable. For fast you might prefer small. Part one is about functionality it has to be there. Part two is about effective product life and part three about performance constraints.

For me, with a working program written in an unfamiliar language, I'd just use it. If it needed enhancement I'd focus first on an analysis of its approach and then look at the merits of tinkering with unfamiliar code (if I had the source) or converting it into a language I favoured. If there was no suitable compiler for my favoured langage I'd consider it time to move on to another language
 
Last edited:
Black Hole said:
I was thinking about this, and about to search though my archive for Modula-2 stuff...
Click to expand...
Found it, it dates back to 1987! It's a DOS executable and won't be long-filename aware (I think that came in with Win98), so I think I can discount it as being of any use except curiosity! It seems I also have a C compiler of similar vintage. Seriously considering modula2.org though.
 
Last edited:
Modula2 is a nice language. I remember lusting after it back in the day, when I was working primarily in Pascal with the odd bit of C. Unfortunately I never got to use it for anything serious. If you like it, use it I'd say!
 
Wow! I just ran a video render on my ZEN machine using Kdenlive in Mint Linux and had all 12 cores at 70%+!

Product is a 124MB 13.5min MP4, from a StDef TS, and took 1m38s (which might be slow because both the source video and the destination mp4 were on a UPD running at USB2 rates).

Update: re-running the same job from and to SATA HDD knocked 23s off that (with no apparent difference in CPU load).
 
Last edited:
Interesting and impressive though these results are (well, at least to me with what is now a low-powered laptop pretending to have 2 cores - I think it only has one core/2 threads (???) but "self-identifies" as 2 core), we are missing a small piece of information. What codec are you using? If, using WinAVI-All-in-One converter, I try to convert an mpg or ts to mp4 it offers me three alternatives: MPEG-4 Video - which takes approximately as long to encode as the duration of the file; ZJ Media MPEG-4 encoder - between 1/4 and 1/2 that time; and H264/AVC - in excess of twice that time. (Using 95%+ of combined processors) Obviously, for the same bit-rate, the quality of the results depend on the encoding time - with ZJ Media being quick-and-dirty, suitable only for poor source material. Using another renderer (probably ffmpeg) I could encode H265 but that would be an all-night job. I suppose another useful variable in comparisons might be the resolution of the source.
 
EEPhil said:
low-powered laptop pretending to have 2 cores - I think it only has one core/2 threads (???) but "self-identifies" as 2 core
Click to expand...
This is an AMD Ryzen with 6 real cores, hyper-threaded (which means each core has two copies of all working registers and can switch between two separate processes practically instantly).

EEPhil said:
I suppose another useful variable in comparisons might be the resolution of the source.
Click to expand...
StDef (as stated) - ie 576i. I can't provide any other stats at the moment because I deleted all the files and the only remaining copy is on a UPD elsewhere... I can update in about a week. However, I suspect Kdenlive rendered to H.264.

Out of interest, I've started a run rendering a 43m41s HiDef TS recording of 2.7GB into MP4, and the cores are up in the 95% area (peaking 99%, contributing to my heating). Obviously there's no purpose in doing it this way except for bragging rights...

Run complete, run time 21m09s, MP4 file is 2.5GB and ffprobe reports "H264".
 
Having bragged about the video encoding performance, I can't say I'm very impressed with video decoding performance. Maybe it's the VLC app, but it won't play the video smoothly unless I restrict the size of the window.
 
You must log in or register to reply here.
Back
Top